e: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

[sthaug at nethelp.no]

> >How about these two?
> >
> >> nullmx.domainmanager.com
> >Non-authoritative answer:
> >Name:    mta.dewile.net
> >Address:  69.59.189.80
> >Aliases:  nullmx.domainmanager.com
> >
> >> smtp.secureserver.net
> >Non-authoritative answer:
> >Name:    smtp.where.secureserver.net
> >Address:  208.109.80.149
> >Aliases:  smtp.secureserver.net
> >
> >There are two reasons it does not blow up in peoples face.  1) If it is in 
> >the CNAME RR points to an A record in the same zone, both the A record and 
> >the CNAME record are returned, thus meeting the A record requirement.  2) 
> >SMTP servers are required to accept an alias and look it up.  Thus there is 
> >no need for this.
> >
> >And no it does not matter if there are multiple MX records with different 
> >preferences values.
> 
> You say, "both the A record and the CNAME record are returned."
> We know that BIND does this.

No, not all BIND versions do this. I'm running BIND 9.5, and when
asking about the MX for nullmx.domainmanager.com I'm getting 

Answer:		nullmx.domainmanager.com.  CNAME  mta.dewile.net.
Authority:	dewile.net.  SOA  ...

Even if my BIND 9.5 name server has the A record for mta.dewile.net
in the cache, it is not returned.

> Is this part of the RFC?  Do other DNS implementation return both
> the "A" and the CNAME?

My ISP's Nominum CNS name server does the same - returns the CNAME
in the answer section, and the SOA for dewile.net in the authority
section. No A record for dewile.net is returned.

However, this whole debate is rather pointless. We clearly have one
person who doesn't want to be convinced. That's okay - but he can't
expect ISC (and Nominum, etc) to change their software just because
he has a different interpretation of the RFCs than the rest of the
DNS world.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no