We’ve had a bind/named resolver running for a long time, forwarding (forward-only on) queries to Cloudflares DNS64 resolvers (2606:4700:4700::64 / 2606:4700:4700::6400 )
Around March 23 2023 02:00-03:00 ish UTC we started experiencing no-responses (NOERROR, QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1) for AAAA-records on IPv4 only domains.
Same query was working and got a reply from same server via dig-command
$ dig +short -taaaa @2606:4700:4700::64 github.com
64:ff9b::8c52:7903
After diffing tcpdumps i managed to identity the difference that makes the difference: the “Non-authenticated data” query flag should be “Unacceptable” for it to work:
This does NOT work:
Domain Name System (query)
Transaction ID: 0x65ff
Flags: 0x0110 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...1 .... = Non-authenticated data: Acceptable
This does work:
Domain Name System (query)
Transaction ID: 0xd825
Flags: 0x0100 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data: Unacceptable
Changing the dnssec-validation from no to yes in named.conf-options solves the problem.
named.conf (Not working)
options {
dnssec-validation no; #Setting this to yes resolves the problem
forwarders { 2606:4700:4700::64; 2606:4700:4700::6400; };
forward only;
}
Requests to bind running with above configuration on ::1:
dnssec-validation = no
$ dig -taaaa @::1 github.com
; <<>> DiG 9.18.12 <<>> -taaaa @::1 github.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40178
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9ef538a524eee59b01000000641d49aea79b17f4af091087 (good)
;; QUESTION SECTION:
;github.com. IN AAAA
;; AUTHORITY SECTION:
github.com. 208 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
dnssec-validation: yes
$ dig -taaaa @::1 github.com
; <<>> DiG 9.18.12 <<>> -taaaa @::1 github.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33871
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c750952e78d049ac01000000641d4a78c99e0c2ce404c0e7 (good)
;; QUESTION SECTION:
;github.com. IN AAAA
;; ANSWER SECTION:
github.com. 19 IN AAAA 64:ff9b::8c52:7904
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Fri Mar 24 08:00:08 CET 2023
;; MSG SIZE rcvd: 95
I’m somewhat (
) sure nothing changed in our end, so I’m suspecting some change in Cloudflares DNS64 implementation.
In case I’m actually right about that: Was this change intended? Does it conform to some RFC and was I wrong requesting without dnssec in the first place?
(Testing Googles public DNS64 seems to behave the same as Cloudflares after the change, so this is probably correct behavior in some way)
Of course DNSSEC validation should be enabled, so this is mostly out of curiosity. Any hints?