> 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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
