Proper CNAME interpretation

[Kevin Darcy]

On 9/14/2011 5:52 PM, Chuck Swiger wrote:
> On Sep 14, 2011, at 2:27 PM, Ronald F. Guilmette wrote:
>> The second part however seems to go more to my question, which is "What is
>> the resolver supposed to do when some knucklehead breaks the rules and puts
>> a CNAME in with some other stuff?"
> Depends on which query one issued.  The very next paragraph of RFC-1034 is:
>
> "CNAME RRs cause special action in DNS software.  When a name server
> fails to find a desired RR in the resource set associated with the
> domain name, it checks to see if the resource set consists of a CNAME
> record with a matching class.  If so, the name server includes the CNAME
> record in the response and restarts the query at the domain name
> specified in the data field of the CNAME record.  The one exception to
> this rule is that queries which match the CNAME type are not restarted."
>
> In other words, if you ask for an A record, and you get back both a CNAME and an A record, then the A record matches and that's what gethostbyname()/getaddrinfo() or whatever should receive from the resolver.  If you asked for an AAAA record, and got that same reply of a CNAME and an A record, then the resolver should chase the CNAME's data field.
>
>> It sure _sounds_ like that second sentence is encouraging any&  all people
>> who are writing resolvers, or other related tools, that they should ignore
>> any flotsam&  jetsum that appear along side a CNAME.  But is that encourage-
>> ment espressed anywhere as a "MUST"?
> By no means.  You only ought to chase a CNAME if you got a CNAME *instead* of the resource type that you asked for.'
Indeed. It should be noted that not only does the graphiteops.com name 
break the "CNAME and other" rule, but it's a *self-referential* CNAME 
(rdata = graphiteops.com), so if one tried to chase it, one could chase 
infinitely. This is, presumably, what RFC 1034 calls a "CNAME loop", and 
according to that document ("Of course, by the robustness principle, 
domain software should not fail when presented with CNAME chains or 
loops; CNAME chains should be followed and CNAME loops signalled as an 
error") I would have expected nslookup and/or dig to have error'ed out 
when encountering this. Are those utilities not considered "domain 
software"? Hard to know, since neither 1034 nor 1035 define that term...


                                                                         
                                                                         
                                     - Kevin