PLEASE READ: BIND 8.2.2 problem

[Jim Reid]

>>>>> "Brian" == Brian Keves <- NCS UAI Contractor <keves at synopsys.com>> writes:

    Brian> We run hosts2ns automatically to convert our NIS hosts file
    Brian> into DNS zone DB files. Since we have such a large number
    Brian> of admins we sometimes end up with CNAMES that have other
    Brian> data, getting the standard messages from named:

    Brian> Apr 27 14:05:51 ankokuji named[24446]: auto/synopsys.com:50225:iei.synopsys.com: CNAME and OTHER data
    Brian> Apr 27 14:05:51 ankokuji named[24446]: master zone "synopsys.com" (IN) rejected due to errors (serial 2000042756)

    Brian> Under Bind 4.9.7 we would get the messages but named would
    Brian> still accept the domain. Under Bind 8.2.2-P5 named rejects
    Brian> the domain and the server quietly becomes non-authoritative
    Brian> for synopsys.com.

Well there's a message in the log saying that the zone has been
rejected so the name server's hasn't exactly "quietly become
non-authoritative". 

FYI it's illegal for a name that exists as a CNAME to exist as any
other record type. [Well with DNSSEC, a CNAME could have SIG and NXT
records.] I quote from RFC1034:

	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.

So what BIND8.2.2-P5 is doing is simply protocol compliance. Older
versions of BIND were much too permissive about data in zone files.

    Brian> I have been looking for an option or something to tell BIND
    Brian> 8.2.2-P5 to just throw out the bad record and not reject
    Brian> the domain. Seems silly to reject the entire domain just
    Brian> because of one error.

I disagree. You're blaming the name server - which is doing the Right
Thing IMHO - for deficiencies in your tools and procedures. Blame the
message, not the messenger. If someone/something does stupid things,
that result in protocol violations it's good that the name server
checks for those stupid things and stops those errors from getting
propagated. Why don't you (a) stop your admins from generating illegal
data; (b) fix the "tool" you use to stop it putting illegal data in
the zone files it generates? It shouldn't be hard to fix h2n or check
the files it produces before presenting them to the name server.