Is this 9.2.2rc1 behavior correct?

[Mark_Andrews at isc.org]

> We are having a problem with our 9.2.2rc1 nameservers interacting with
> elmresources.com.  Basically, they get to a point where they stop
> resolving any hosts in that domain (eg www.elmresources.com).
> 
> Looking at their nameserver configuration (via dig) shows that the
> nameservers for elmresources.com are mail.elmresources.org and
> ns1.elmresources.org which in turn are CNAMEs pointing to
> ns2.elmresources.org and newbox.elmresources.org respectively.
> Obviously the best correction is to remove the CNAME indirection (or
> get the nameservers changed to the real names).
> 
> But I'm concerned that there may be a bug here.  That or CNAMEs as the
> target of NS records need to be made explicitly illegal.  RFC-1912 is
> unambiguous that this is a bad thing, but stops short of declaring it
> illegal.
> 
> The problem, I believe, is glue records.  that two of the top level COM
> nameservers (a.gtld-servers.net and g.gtld-servers.net) return A
> records for these two hostnames (mail.elmresources.org and
> ns1.elmresources.org) in their additional data section.  The other 11
> nameservers return just the NS records and no additional data.
> 
> Now, when I dump the cache on a nameserver that isn't resolving domains
> I see:
> 
> ; glue
> elmresources.COM.       171719  NS      NS1.ELMRESOURCES.ORG.
> 			171719  NS      MAIL.ELMRESOURCES.ORG.
> ...
> ; glue
> MAIL.ELMRESOURCES.org.  171085  A       208.253.213.2
> ; authanswer
>                         9085    CNAME   ns2.ELMRESOURCES.ORG.
> ; glue
> NS1.ELMRESOURCES.org.   171085  A       64.71.130.98
> ; authanswer
>                         9085    CNAME   newbox.ELMRESOURCES.ORG.
> 
> While, on a nameserver that is resolving their domain, I just see A
> records, not the CNAMEs.
> 
> The folks at elmresources.com say we are the only customer experiencing
> a problem.  And indeed I am unable to reproduce this situation with a
> 9.2.1 server.
> 
> So are a.gtld-servers.net and g.gtld-servers.net  wrong for returning
> the glue records?  Or are the others wrong for not returning them?
> 
> And is 9.2.2rc1 bind wrong for not discarding the A glue record once it
> follows the CNAME chain?  Or wrong for refusing to talk to the hosts
> once the conflicting data is in the cache?  I very much hesitate to
> call this a bug but it certainly represents a departure from previous
> behavior.
> 
> If, as I suspect, the root nameservers are correct for returning the
> glue records and 9.2.2.rc1 is correct for refusing to accept a host
> with both A and CNAME data, then doesn't that mean that CNAMEs for
> nameservers will always get into this state?
> 
> Thoughts?

	No version of BIND has followed CNAMES when looking up
	address records for nameservers.  This configuration will
	cause problems with *every* version of BIND in existance.

	BIND 8.3.x will fail on the second lookup for the zone.
	The AAAA/A queries for missing glue will cause the CNAME to
	be cached.

	BIND 4 and 8.x (x<3) will fail if the were any lookups for
	types other than A records for the nameservers.  These will
	cause the CNAME to be cached.  Subsequent lookups will fail.

	BIND 9 also breaks once it detects a CNAME.

	NS records pointing to CNAMES have always been illegal.

	To make them work you would have to change the additional
	section processing rules to follow CNAME chains.  Nameservers
	would have to chase CNAME chains for nameservers.  Registrars
	would have to accept CNAME chains as glue.

	None of this is in RFC 103[345].

	On top of that you have to break the SHOULD in RFC 1034
	that all records refering to other record SHOULD refer to
	the primary name not aliases.  The only accepted exception
	to this rule is that ALIASES can refer to ALIASES.

RFC 1034:
"Domain names in RRs which point at another name should always point at
the primary name and not the alias.  This avoids extra indirections in
accessing information.  For example, the address to name RR for the
above host should be:

    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

rather than pointing at USC-ISIC.ARPA.  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."

	When RFC 103[345] was written sites actually followed not
	only the words of the RFC's but the spirit of the RFC's.

	RFC 2181 Section 10.3 makes the SHOULD about into a MUST
	for NS and MX records.

RFC 2181:
"10.3. MX and NS records

   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR."

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org