1

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?

1
  • Prefer dig over nslookup but in both cases if I am not wrong, if you do not specify the type, an A type query is done. If you want AAAA you need to specify it explicitely (and it is good practice anyway). Both are doing DNS queries themselves so they do not care about gai.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) Apr 7, 2020 at 3:22

1 Answer 1

1

If you refer to the nslookup contained in the dnsutils package:

  • Debian 9: 9.10.3
  • Debian 10: 9.11.5
  • Ubuntu 18.04: 9.11.3

I believe that the functionality you are missing in Debian 9 (9.10.3) was introduced with this commit:

4420. [func] nslookup now looks for AAAA as well as A by default.

It was then released as a beta- and release candidate-version both of which later became the stable 9.11.0 of bind and its utils.

In order to obtain a later version for Debian 9, you may check out the stretch-backports repository, which will enable you to install 9.11.5 in a clean manner on Debian 9.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .