CNAME Misconfiguration? Discrepancy between Bind 8.2.3 and Bind8.2.2?

Erik Aronesty erik at primedata.org
Fri Feb 23 22:25:50 UTC 2001


Yes, this is an incompatibility between 8.2.2 and probably an error in the RFC.  SOA and NS data are more like KEY/TSIG data - in that they are not "resource records" they are "dns maintenance" records - and have special rules regarding their handling.

The fact that you cannot have a CNAME at the root of a zone is clearly not the intention of canonical names - especially since DNS is not BIND - and has no "implied file system" built in to the protocol.  All records have implied SOA's and NS's associated with them - regardless of where they occur.

A workaround is to put the CNAME in the "parent zone".  In this case you would have to create a zone file for "COM" and then put mytestdomain.net in it.  Of course that's just a horrible hack to get around the inconsistency in the specification.

If you want to, I have an easy patch to BIND 8.2.3 that allows CNAME's anywhere you need them.

			- Erik

-----Original Message-----
From:	Thor Kottelin [SMTP:thor at anta.net]
Sent:	Friday, February 16, 2001 4:52 PM
To:	comp-protocols-dns-bind at moderators.isc.org
Subject:	Re: CNAME Misconfiguration? Discrepancy between Bind 8.2.3 and Bind8.2.2?




digest at cihost.com wrote:
> 
> After upgrading to BIND 8.2.3, every single record of mine based entirely on
> CNAMES appears to not work now, can someone explain to me why they wouldn't
> work?

> $ORIGIN net.
> mytestdomain   IN   SOA  ns.nsdomain.net. hostmaster.nsdomain.net. (
>                 2000051920 86400 7200 3600000 28800 )
>                 IN      NS      ns.nsdomain.net.
>                 IN      NS      ns2.nsdomain.net.
>                 IN      CNAME   otherdomain.com.

> Feb 13 19:26:36 vns2 named[761]: mytestdomain.net has CNAME and other data
> (invalid)

> What would make this invalid?

The fact that mytestdomain.net owns both a CNAME and other data.

"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." - RFC 1034

Thor

-- 
Plain old email is very insecure. Please make it                     !gc
a little safer for yourself and me by using PGP.
FAQ: <URL:http://www.pgp.net/pgpnet/pgp-faq/>.			
My public keys are available from key servers.            IRCnet #areena






More information about the bind-users mailing list