On Sun, Apr 28, 2024 at 2:18 AM Walter H. wrote: > > On 27.04.2024 16:54, Lee wrote: > > On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users > > <bind-users@lists.isc.org> wrote: > >> # host dnssec-analyzer.verisignlabs.com > >> dnssec-analyzer.verisignlabs.com is an alias for > >> dnssec-analyzer-gslb.verisignlabs.com. > >> dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 > >> > > Right, the IPv4 address lookup works. Now try looking up the IPv6 address. > > if there was one it would be presented there
Try this: $ dig www.github.com aaaa ; <<>> DiG 9.16.48-Debian <<>> www.github.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45964 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1432 ; COOKIE: 6e0635047fb42cbf01000000662ff80b95c1aaed2c48a54b (good) ;; QUESTION SECTION: ;www.github.com. IN AAAA ;; ANSWER SECTION: www.github.com. 3600 IN CNAME github.com. ;; AUTHORITY SECTION: github.com. 3600 IN SOA dns1.p08.nsone.net. hostmaster.nsone.net. 1656468023 43200 7200 1209600 3600 The query status is NOERROR. Compare that to $ dig dnssec-analyzer-gslb.verisignlabs.com aaaa ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer-gslb.verisignlabs.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18045 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1432 ; COOKIE: 8dca27caaec9a47401000000662ff8ad9cc9bff9bf779d54 (good) ;; QUESTION SECTION: ;dnssec-analyzer-gslb.verisignlabs.com. IN AAAA where the query status is SERVFAIL. OK.. noerr vs. servfail doesn't make all that much difference to me, but I *would* like to understand why looking ip the IPv6 address for that name gives me an error. I'm still operating under the (increasingly looking like it's delusional) assumption that I should be able to understand this stuff. > this can't be a matter of DNSSEC, as there are only signed whole zones > and not just single DNS-records ... I dunno. I've seen some weird stuff with servers on AWS not resolving IPv6 addresses but having a CNAME pointing outside the zone. Which I don't understand, but at least it doesn't return an error so I just chalked it up to them deciding that supporting IPv6 was too much of a pain. Regards, Lee -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users