CNAME query

Havard Eidnes he at uninett.no
Thu Sep 23 13:04:33 UTC 2021


> Don't know if that helps, but if I query my local Bind DNS for a CNAME,
> that doesn't exists, dig gives me the SOA record:
>
>> dig cname nonexisting.example.com @mydns
>
> ; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22683
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;nonexisting.example.com.             IN      CNAME
>
> ;; AUTHORITY SECTION:
> example.com.              600     IN      SOA     mydns.example.com. hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800
>
> ;; Query time: 0 msec
> ;; SERVER: mydns#53(mydns)
> ;; WHEN: thu sep 23 13:50:00 CEST 2021
> ;; MSG SIZE  rcvd: 100

More importantly, perhaps, is that it returns NXDOMAIN status,
which indicates that "the name that you queried for does not
exist" -- in other words, there doesn't exists any other resource
records (of a different type) at the queried-for name, and there
doesn't exist any data "below" the queried-for name either.

Furthermore, the response has the 'aa' flag set, indicating an
"authoritative answer".  This means that the answer came from a
name server which is set up to serve queries for the enclosing
zone (i.e. it didn't come from a cache on a recursive resolver).

The SOA record in the authority section basically says from which
zone the negative response originates, and the "minimum" value in
the SOA record indicates to a caching recursive resolver how long
it ought to cache the information that the queried-for name
doesn't exist (so that negative answers can be provided from the
cache instead of having to bother one of the publishing name
servers for the zone each time).

Lastly, there is no DNSSEC validation being performed (no "ad"
for "authentic data" asserted as a flag), and since the query
wasn't done with "+do" flag ("DNSSEC OK"), no DNSSEC records are
returned (even if they existed).


If, on the other hand, you had queried

dig cname example.com @mydns

you would in all probability get

1) an answer with "status: NOERROR", because the queried-for name
*does* exist in the name tree, as there exists other record types
at the queried-for name, just no CNAME records (which is natural,
since CNAME cannot legally coexist with other record types at the
same name, and at the top of the zone you must have SOA and NS
records).

2) an SOA record in the authority section, as above.

3) the 'aa' flag set again, as above.

4) no DNSSEC processing etc., as above.


Best regards,

- Håvard


More information about the bind-users mailing list