0

I know you can test if a DNS server is valid by running:

 dig +short test_hostname @nameserver

But what if we don't have a test_hostname to test queries with? For example if the system we want to run this command on is within a restricted network and we don't know what hostnames they have access to or are available on their network.

Would using localhost as the test_hostname be a reliable way of checking if this is a valid DNS server?

Or I did notice that dig, host, nslookup will all return:

;; connection timed out; no servers could be reached

if you type in an invalid DNS server regardless of what test_hostname you type in, so would just running:

dig +short @nameserver

be a reliable way of checking if the DNS server is valid? There is no need to check if the DNS server is fake/malicious or not, just if it is valid or invalid.

  • 1
    It's common to have `localhost` in a nameserver, but there's no guarantee. I don't think there's any generic query that you could use. – Barmar Mar 05 '20 at 00:25
  • 1
    It is still unclear what exactly do you mean by "valid". Is server valid if it is up and running but can't resolve any name? Or if it can resolve only one specific name but not anything else? Or it can resolve internal domain names but not public ones? – Dusan Bajic Mar 05 '20 at 07:49
  • I would consider all of those to be valid – Calvin Maedal Mar 05 '20 at 21:35

2 Answers2

0

Try:

dig . ns @nameserver +short

Even if the server has no root nameservers configured, if it's alive it will respond to this. If there are root servers, you'll get a valid list of NS records; if not, you'll get an empty response with rcode=NOERROR.

Barmar
  • 741,623
  • 53
  • 500
  • 612
  • "Every nameserver needs to be initialized with the root server list" That is valid only for recursive nameservers, authoritative ones do not need that root server list. In fact upward referals are now considered harmful: https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful – Patrick Mevzek Mar 05 '20 at 18:38
  • Even if the server isn't recursive, it will come with a built-in root server list. Or you can override it with a list that points to itself. Either way, it will have something. – Barmar Mar 05 '20 at 18:58
  • I still do not agree. It may come, by default, with such a list, but can be as well configured to not have any at all, and not do upward referral at all (only case were an authoritative nameserver will need such a list, in all other cases there is no need of that list of root servers) – Patrick Mevzek Mar 05 '20 at 20:11
  • OK, I've revised my answer. You'll get a response that you can check for validity, but the contents will depend on whether the root servers are configured. – Barmar Mar 05 '20 at 20:34
0

You are not saying if you are testing a recursive or an authoritative nameserver.

You also need to define valid. Do you expect a DNS reply for your query?

You can test with known invalid/not-existing names such as whatever.test or whatever.example. You should always get a DNS reply back, even if it is NXDOMAIN, or possibly NOERROR in a case of upward referral.

Note that if you do that towards server you do not control, depending on the rate, people may start to notice and rate limit you or worse.

You can also try to query the CHaos zone, however this is often disabled. It is one way to "identify" a given nameserver software.

Example:

$ dig @a.root-servers.net version.bind TXT chaos +short
"NSD"

Even if the feature is disabled you should get back a DNS reply with REFUSED or NOTIMP or some kind of return code like that:

$ dig @ns1.google.com version.bind TXT chaos

...

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 57909
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

PS: note that dig has a header-only flag that allows to send a question with just a header and no content (that is not need to specify a name).

Not all nameservers may react to that properly though, same may just timeout and not reply at all.

Patrick Mevzek
  • 10,995
  • 16
  • 38
  • 54