A data point for the "CNAME and other data at zone apex" discussion

Cricket Liu Cricket at VeriSign.com
Mon Mar 5 02:59:49 UTC 2001


I'm going to post this without much comment, because I
find the discussion of this topic (if you can call it that) about
as edifying as shouting at the wind.

I happened to run across this when answering a question
about a resolution problem.  I thought it was interesting to
see how the name server in question, running BIND 8.2.2-P7,
handled having cached a CNAME RR and other RRs.

Note that the kasenna.net name servers are both returning
SERVFAIL for queries in kasenna.net, but correct responses
for queries in kasenna.com.  So the SERVFAIL responses
you see are a by-product of the name server trying to follow
the CNAME RR, not an inherent reaction to having CNAME
and other RRs for the same domain name cached.

Here goes:

$ dig @ns2.westhost.net. version.bind. txt chaos

; <<>> DiG 9.1.1rc3 <<>> @ns2.westhost.net. version.bind. txt chaos
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48651
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
VERSION.BIND.           0       CH      TXT     "8.2.2-P7"

$ dig @ns2.westhost.net. any kasenna.com.

; <<>> DiG 9.1.1rc3 <<>> @ns2.westhost.net. any kasenna.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13019
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;kasenna.com.                   IN      ANY

;; ANSWER SECTION:
kasenna.com.            28800   IN      CNAME   kasenna.net.
kasenna.com.            123382  IN      NS      NS1.PBI.net.
kasenna.com.            123382  IN      NS      NS1.kasenna.com.
kasenna.com.            38612   IN      SOA     NS1.kasenna.com.
root.NS1.kasenna.com. 2001022701 3600 900 86400 43200

$ dig @ns2.westhost.net. a kasenna.com.

; <<>> DiG 9.1.1rc3 <<>> @ns2.westhost.net. a kasenna.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34801
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kasenna.com.                   IN      A

;; ANSWER SECTION:
kasenna.com.            28800   IN      CNAME   kasenna.net.
$ dig @ns2.westhost.net. mx kasenna.com.

; <<>> DiG 9.1.1rc3 <<>> @ns2.westhost.net. mx kasenna.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15219
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kasenna.net.                   IN      MX

$ dig a kasenna.com.

; <<>> DiG 9.1.1rc3 <<>> a kasenna.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44965
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;kasenna.com.                   IN      A

;; ANSWER SECTION:
kasenna.com.            43200   IN      A       208.37.137.68

$ dig mx kasenna.com.

; <<>> DiG 9.1.1rc3 <<>> mx kasenna.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15063
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;kasenna.com.                   IN      MX

;; ANSWER SECTION:
kasenna.com.            43200   IN      MX      50 monitor.kasenna.com.
kasenna.com.            43200   IN      MX      10 merrimack.kasenna.com.

So this means that, should you hack your name server to allow "CNAME
and other data" and add a CNAME at your zone apex, you'll make your
own zone's A and MX RRs unresolvable, at least for some name servers.

If we use the example of adding an alias like this to your zone:

foo.example.    IN    CNAME    www.webhostingcompany.com.

this implies that people who cache the CNAME record and then look up
the foo.example A or MX RRs will end up retrieving the A or MX RRs
for www.webhostingcompany.com.

cricket



More information about the bind-users mailing list