Score:1

nslookup finds IP address, but still claims NXDOMAIN

cn flag

In my network I have:

  • mikrotik router (10.0.0.1) with static DNS entries for myhost.mydomain.com -> 10.0.0.4
  • adguard server (10.0.0.128) that uses 10.0.0.1 as upstream DNS
  • DHCP gives 10.0.0.128 as primary DNS.

I have really weird situation with DNS resolution on ubuntu machines:

[21:22:18][root@ubuntu]:~# nslookup myhost.mydomain.com
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   myhost.mydomain.com
Address: 10.0.0.4
** server can't find myhost.mydomain.com: NXDOMAIN

So - the name resolved into 10.0.0.4, but somehow it still says NXDOMAIN - what's up with that?

What's even weirder, when I logged in to my domain registrar and added a CNAME entry for *.mydomain.com that points to mydomain.com (which resolves to IP of my hosting provider) - here's what I see:

[21:58:04][root@ubuntu]:~# nslookup myhost.mydomain.com
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   myhost.mydomain.com
Address: 10.0.0.4
myhost.mydomain.com    canonical name = mydomain.com.

However, from my daily driver (macOS) I'm not getting this issue:

[20:46:57][shalak@shalak-mac]:~$ nslookup myhost.mydomain.com
Server:     10.0.0.128
Address:    10.0.0.128#53

Non-authoritative answer:
Name:   myhost.mydomain.com
Address: 10.0.0.4

What's going on here?

cn flag
I would suggest using `dig` instead for clarity, but if you must use `nslookup` I would advise that you at least use its debug mode (eg `nslookup -debug foo.example.com`), where it's at least clear which lookups it did and what each individual answer looked like. The default mode of `nslookup` is not troubleshooting friendly as it likes to send multiple different queries and produces output that may happily mix parts of different responses. I kind of assume that something like that may be happening where you see what appears to be both a successful response and NXDOMAIN at the same time.
Nikita Kipriyanov avatar
za flag
Mikrotik's DNS is extremely dumb and I'm afraid you can't just use it in place of proper DNS server. For a small network it's OK if you don't have any other DNS and you don't use it as a kind of "origin" nameserver and it has a proper upstream, but if you do have proper DNS server, use it for all resolution in the network and don't rely on Mikrotik's, in particular, don't set up Mikrotik itself as an upstream to a DNS server. For the case, I think Mikrotik doesn't send "authoritative response" and it makes systemd resolver to dig further.
Score:2
fr flag

So - the name resolved into 10.0.0.4, but somehow it still says NXDOMAIN - what's up with that?

nslookup makes two queries: one for A records and another for AAAA records (IPv6 addresses). Normally, both queries should either succeed or fail equally (regardless of what kind of addresses the domain has – no IPv6 addresses just means an empty successful answer).

But some resolvers (and in particular, some ad blockers) misunderstand the DNS protocol and reply with NXDOMAIN whenever the requested record type doesn't exist, even though the name exists in general. (In fact, I think I remember Adguard doing so deliberately, in order to "block IPv6 leaks" or something.)

Use nslookup -q=A and nslookup -q=AAAA to compare the results.

Use a packet capture tool to verify whether Adguard is receiving the NXDOMAIN from upstream (i.e. from Mikrotik) or whether it's inventing the response on its own decision. (If it's the Mikrotik, make sure you're running the latest firmware.)

Mirek avatar
cn flag
So I see that any client may make any kind of request. I found this particular `nslookup` issue while trying to troubleshoot other issues I have with DNS - e.g. I'm unable to add a CalDAV profile from Nextcloud (which is not exposed to the internet), because MacOS is somehow getting wrong SSL cert for the calendar - nextcloud.mydomain.com has let's encrypt, but somehow MacOS sees the certificate of my hosting provider. Which happens, as I understand, as a result of some weird DNS query it makes, thus falling into the CNAME I added in public DNS. Thanks for the explanation! I'll dig deeper.
Score:2
gh flag

It's a bug in RouterOS 7.7 - I spent 2 days to troubleshoot it :( Solution: downgrade, or install 7.8beta3

from Changelog for 7.8b3:

*) dns - respond with "NOERROR" to DNS requests for static domain names when appropriate type record is not configured or found on upstream server;

Mirek avatar
cn flag
Huh, must be something else, because I'm still on v6.49.7. But good to know, I was about to upgrade, I guess I'll give it a while. Thanks!
Torx avatar
gh flag
I have the 100% same behavior as you describe (also resolving and NXDOMAIN in nslookup) with 7.7 (cause I have RB5009 Router I can't install 6.x firmware), but with 7.8b3 it was fixed without any changes in setup. If you could accept some downtime - backup, update, test and downgrade if something goes wrong.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.