I have an AAAA-only DNS name: superdns.cyberfusion.cloud
. Using nslookup
without options on Debian 9, I get No answer
. Using nslookup
without options on Ubuntu, I get the correct answer (AAAA record). I cannot reproduce this behaviour on Debian 10, though...
Ubuntu 18.04:
$ nslookup superdns.cyberfusion.cloud
Server: 2a0c:eb00:0:f7:185:233:175:142
Address: 2a0c:eb00:0:f7:185:233:175:142#53
Non-authoritative answer:
Name: superdns.cyberfusion.cloud
Address: 2a0c:eb00:0:f7:185:233:175:211
Debian 9 in my network:
$ nslookup superdns.cyberfusion.cloud
Server: 2a0c:eb00:0:f7:185:233:175:142
Address: 2a0c:eb00:0:f7:185:233:175:142#53
Non-authoritative answer:
*** Can't find superdns.cyberfusion.cloud: No answer
Debian 10 in my network:
$ nslookup superdns.cyberfusion.cloud
Server: 185.233.175.142
Address: 185.233.175.142#53
Non-authoritative answer:
Name: superdns.cyberfusion.cloud
Address: 2a0c:eb00:0:f7:185:233:175:211
Debian 9 outside my network using Cloudflare DNS:
$ nslookup superdns.cyberfusion.cloud
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
*** Can't find superdns.cyberfusion.cloud: No answer
So, I started looking at differences between these three machines, but could not find any significant lookup-related configuration errors:
Same gai.conf
on all machines:
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label fc00::/7 6
No systemd-resolved
on all machines:
$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-resolved.service.d
└─resolvconf.conf
Active: inactive (dead)
And, as mentioned before, I have tested on two Debian 9 machines with different resolvers in use.
The only common characteristic I could find is that the machines with 'wrong' behaviour run Debian 9, whereas the machines with 'correct' behaviour run either Ubuntu or Debian 10. I have searched Debian 10 changelogs for IPv6-related changes, but could not find many.
This behaviour is not specific to nslookup
. I use some Ruby DNS library that does not find the AAAA record on the machines where nslookup
is not finding my AAAA records, but does find the AAAA record on the machines where nslookup
is finding my AAAA records, so this must be a system-wide setting.
Question: aside from /etc/gai.conf
, which mechanism controls whether to look for AAAA records at all?
dig
overnslookup
but in both cases if I am not wrong, if you do not specify the type, anA
type query is done. If you wantAAAA
you need to specify it explicitely (and it is good practice anyway). Both are doing DNS queries themselves so they do not care aboutgai.conf
or if a local resolver runs or not (you can specify which nameserver you want to query which is always something good to do explicitely)