Right, BIND 9.18 now enforces Section 2.2 of RFC 5936, specifically, this:
"The AXFR server MUST copy the
Question section from the corresponding AXFR query message into the
first response message's Question section. For subsequent messages,
it MAY do the same or leave the Question
That gets me more information, and I think puts the problem onto
axfrdns. Thanks.
xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of
initial version from 198.51.100.1#53
xfer-in: info: transfer of 'example.net/IN' from
Set debug level 3 on the xfrin channel. There are some debug level messages
that really should be set to error level in lib/dns/xfrin.c on FORMERR.
Also make sure you are running dig from the same version as later versions are
more strict in parsing responses from the wire.
> On 1 Sep 2023,
I have a system running BIND 9.18.17 that needs to transfer a zone from
djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log
messages indicating the problem.
xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: info: transfer of 'example.net/IN' from
The servers don’t respond to DNSKEY queries. No every error is an indication
that the validator should switch tracks from proving an answer is secure (the
server is sending signed responses) to proving that it is insecure.
> On 31 Aug 2023, at 17:28, stuart@registry.godaddy wrote:
>
> This is
This is odd.
“incometax.gov.in” hasn’t published a DS record, so no DNSSEC validation should
be occurring for any child. The registry object hasn’t been changed since 2022,
so its behaviour should be nothing new.
Testing various public verifying resolvers (google, cloudflare, local unbound
6 matches
Mail list logo
