dig resolves a subdomain, but no other tool does

Question

I created a new CNAME under my domain and waited for a while (about 1h).

Then I tried creating a letsencrypt certificate and got DNS resoution errors, so I started testing the name resolution on my own.

It turns out that dig can find the CNAME without issues, no matter which nameserver I use, but nslookup and host just can't.

As an example, here is the output I get when using 1.1.1.1:

root@pre ~ # dig my.subdomain.com @1.1.1.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> my.subdomain.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8098
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;my.subdomain.com.             IN      A

;; ANSWER SECTION:
my.subdomain.com.      113     IN      CNAME   \@.

;; AUTHORITY SECTION:
.                       9382    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2020040300 1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Apr 03 12:37:55 CEST 2020
;; MSG SIZE  rcvd: 136

root@pre ~ # nslookup my.subdomain.com 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

** server can't find my.subdomain.com: NXDOMAIN

root@pre ~ # host my.subdomain.com
Host my.subdomain.com not found: 3(NXDOMAIN)
root@pre ~ # cat /etc/resolv.conf
nameserver 1.1.1.1

Some considerations:

1. There are similar questions out there, but the ones I found end up either comparing only dig and nslookup or querying different name servers.
2. I am aware of the nslookup deprecation warnings, but afaik host and dig should be consistent with each other if they use the same name server.
3. If I try any other thing, like curl or ping, name resolution also fails. Only dig seems to figure it out.
4. The same behavior can be observed if I run the commands on other machines and networks, and even if I use online tools. Google dig works (https://toolbox.googleapps.com/apps/dig/), but Kloth.net nslookup does not (http://www.kloth.net/services/nslookup.php)

Can you help me understand what's happening?

Answer 1

No, if you look closely, dig actually gives you the same response as host/nslookup do. The header shows exactly the same NXDomain ("Nonexistent domain") error code.

Following CNAME records is the responsibility of the recursive resolver (in this case 1.1.1.1), not of the client. Since you made a query for 'A' records, the resolver will try to follow the entire CNAME chain until it reaches the final target, so that it could in fact give you the requested 'A' records.

But in this case, the resolver was not able to do that, because your CNAME points to a nonexistent target. It doesn't matter that the resolver was able to find the CNAME itself – that was only part of its job, and it returns a NXDomain error because it was unable to resolve the complete chain.

The resolver did return an 'Answer' section with the part of the chain that it was able to find – notice that your CNAME target is @., which is definitely not a valid TLD.

The @ macro is not part of the DNS network protocol – it is only part of the "zonefile" configuration format commonly used to store DNS entries in a text file. Nameservers will expand it to the real zone name when loading data into memory, and clients should never see it (like browsers should never see <?php in a webpage).

However, each and every web-based DNS control panel basically invents their own config format. They do not always honor such shortcuts, or honor them only in the "name" but not in the "target" field, etc. (There are other variations as well; e.g. some control panels add the domain suffix if the target doesn't end with . but other places don't, in the name of "convenience".)

Fix this by manually changing the CNAME target to subdomain.com. instead of using the @ macro.