6

It seems my default (router) DNS server returns different results depending on the tool used to query it.

  1. Using dig:

    $ dig @192.168.1.2 test.example.com
    
    ; <<>> DiG 9.16.8-Debian <<>> @192.168.1.2 test.example.com
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58608
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;test.example.com.    IN  A
    
    ;; ANSWER SECTION:
    test.example.com.  41  IN  CNAME  123.123.12.123.
    
    ;; AUTHORITY SECTION:
    .      3357  IN  SOA  a.root-servers.net. nstld.verisign-grs.com. 2020112400 1800 900 604800 86400
    
    ;; Query time: 0 msec
    ;; SERVER: 192.168.1.2#53(192.168.1.2)
    ;; WHEN: Tue Nov 24 10:12:40 CET 2020
    ;; MSG SIZE  rcvd: 148
    
    

As you can see, it successfully finds the IP address of test.example.com, which is 123.123.12.123. However, the following two tools do not.

  1. Using host:

    $ host test.example.com 192.168.1.2
    Using domain server:
    Name: 192.168.1.2
    Address: 192.168.1.2#53
    Aliases: 
    
    Host test.example.com not found: 3(NXDOMAIN)
    
  2. Using nslookup:

    $ nslookup test.example.com 192.168.1.2
    Server:    192.168.1.2
    Address:  192.168.1.2#53
    
    ** server can't find test.example.com: NXDOMAIN
    

What is going on here? Why is there a difference between the results of dig, host, and nslookup? Don't they all perform the same DNS queries under the hood?

Edit: as the accepted answer points out, I incorrectly used a CNAME instead of an A record. I have since updated the DNS entry and now the domain name resolves correctly.

Edit2: domain and IPs are fake

0
13

Defining this:

test.example.com.       IN  A 123.123.12.123

would be correct.

This:

test.example.com.    41  IN  CNAME   123.123.12.123.

is invalid. A CNAME must point to an entry that appears on the left: a name, not an IP address.

Here the IP address and its final dot is taken as a name anyway, that's why the authority section refers to a root DNS server a.root-servers.net., because even the lowest part (which would be 123.) can't be found according to it.

So the first command (dig) reports the answer it got while also telling NXDOMAIN, while the two other commands can't resolve the final result and just tell NXDOMAIN.

4
  • 4
    Indeed, a CNAME RR has a name-typed value and the problem occurring here is that the 104.248.81.197. value is "clearly" an all-numeric name (not an IP address!), and this all-numeric name does not resolve to any IP address. Nov 24 '20 at 11:03
  • Yes I'll add this in the answer
    – A.B
    Nov 24 '20 at 11:03
  • 2
    btw: OP corrected the entry, it now resolves correctly.
    – A.B
    Nov 24 '20 at 18:44
  • And because the CNAME it points to is faulty, all three tools return NXDOMAIN. dig just returns the entire answer section as well, which shows the bad answer.
    – Shadur
    Nov 24 '20 at 21:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.