DNS alias found where canonical name expected errors...

[Mark.Andrews at nominum.com]

> In article <9ba8db$cr6 at pub3.rc.vix.com>, jschultz  <jschultz at jhu.edu> wrote:
> >Hey guys, I know this question was asked and answered before but I'm
> >still having problems with looking up machine names that have chains of
> >CNAMEs.
> ...
> >Now if BIND runs across an illegal setup, like the following:
> ...
> >www.cs.jhu.edu.	2h2m38s IN CNAME  condor.cs.jhu.edu.
> >condor.cs.jhu.edu.	1h40m20s IN CNAME  web.cs.jhu.edu.
> >web.cs.jhu.edu.	1h40m20s IN A	128.220.13.101
> ...
> >And a client process requests a lookup of www.cs.jhu.edu, will BIND
> >respond with an error saying something along the lines of "CNAME found
> >where canonical name expected" or will it just follow the chain of
> >CNAMEs until it gets to the A record?
> 
> That error message is coming from my resolver library, adns.
> You can see it in the adns command line test tools too:
> 
> -davenant:~> adnshost --debug www.cs.jhu.edu
> ...
> adns debug: allegedly canonical name condor.cs.jhu.edu is actually alias for 
> web.cs.jhu.edu (QNAME=www.cs.jhu.edu, QTYPE=A(addr), NS=127.0.0.1)
> www.cs.jhu.edu CNAME condor.cs.jhu.edu
> Error during DNS A lookup for www.cs.jhu.edu: DNS alias found where canonical
>  name wanted
> -davenant:~> 
> 
> >This implies to me that BIND is either responding with a CNAME chain
> >ERROR or that adns is making multiple queries for the A record that I
> >request and balks when it sees a CNAME chain. But even if the second
> >case is what is happening shouldn't the adns_qf_cname_loose option allow
> >this? Any ideas?
> 
> No, BIND is not detecting or reporting the erroneous CNAME chain, adns
> is.  BIND is functioning fine (if the authors of BIND want to return
> CNAME chains when they are configured by inexperienced zone authors
> then I have no objection to that).
> 
> Someone else said that CNAME chains *are* legal.  This is not true.

	They are legal. 

RFC 1034 5.2.2. Aliases

...

Several special conditions can occur with aliases.  Multiple levels of  
aliases should be avoided due to their lack of efficiency, but should
not be signalled as an error.  Alias loops and aliases which point to
non-existent names should be caught and an error condition passed back
to the client.


> 
> RFC2181 `Clarifications to the DNS Specification':
> 
> 10.1. CNAME resource records
> 
>    The DNS CNAME ("canonical name") record exists to provide the
>    canonical name associated with an alias name.  There may be only one
>    such canonical name for any one alias.  [...]

	This is a prohibition against multiple CNAME's with the same
	owner not against CNAME chains.

	BIND 4 originally allowed multiple CNAMES with the same owner.
	BIND 8 allows them iff you set "multiple-cnames yes;".
	BIND 9 refuses to load the zone if they are there.

	It is re-stating that following is illegal.

		foo.example.com CNAME alias1
		foo.example.com CNAME alias2

RFC 1034 3.6.2. Aliases and canonical names

...

The domain system provides such a feature using the canonical name
(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR.  If a CNAME RR is present at a node, no other data should be   
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.

	The "no other data" includes other CNAME records.  BIND 4's
	original checks did not take this into account.

 
> ...
> 10.1.1. CNAME terminology
> ...
>                    [...] the label of a CNAME record is most certainly
>    not a canonical name.  [...]
> 
> This is also documented in numerous other places.
> 
> adns never follows more than one CNAME.

	ADNS' behaviour is broken in this respect.

>  This is to avoid the need for
> complicated loop detection algorithms or arbitrary limits on the
> number of CNAMEs which will be traversed.  If adns finds that the
> target of a CNAME is another CNAME, you will get the `DNS alias found
> where canonical name wanted' error, which is an adns error code.
> 
> adns will also not by default follow CNAMEs found as a result of MX or
> similar lookups; this can be relaxed with the `loosecname' query flag.
> However, the CNAME chain prohibition cannot be relaxed.  Simply
> removing the test for the error condition would make the resolver go
> into an infinite loop when it found a CNAME loop.
> 
> So, in summary, your zone data is wrong and you must fix it.

	No. ADNS is broken.
> 
> -- 
> Ian Jackson, at home.           Local/personal: ijackson at chiark.greenend.org.
> uk
> ian at davenant.greenend.org.uk       http://www.chiark.greenend.org.uk/~ijackso
> n/
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com