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

  1. Using dig:

    $ dig @ test.example.com
    ; <<>> DiG 9.16.8-Debian <<>> @ 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
    ; EDNS: version: 0, flags:; udp: 512
    ;test.example.com.    IN  A
    test.example.com.  41  IN  CNAME
    .      3357  IN  SOA  a.root-servers.net. nstld.verisign-grs.com. 2020112400 1800 900 604800 86400
    ;; Query time: 0 msec
    ;; SERVER:
    ;; 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 However, the following two tools do not.

  1. Using host:

    $ host test.example.com
    Using domain server:
    Host test.example.com not found: 3(NXDOMAIN)
  2. Using nslookup:

    $ nslookup test.example.com
    ** 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


1 Answer 1


Defining this:

test.example.com.       IN  A

would be correct.


test.example.com.    41  IN  CNAME

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
    Indeed, a CNAME RR has a name-typed value and the problem occurring here is that the 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, 2020 at 11:03
  • Yes I'll add this in the answer
    – A.B
    Nov 24, 2020 at 11:03
  • 2
    btw: OP corrected the entry, it now resolves correctly.
    – A.B
    Nov 24, 2020 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. Nov 24, 2020 at 21:34

You must log in to answer this question.

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