PLEASE READ: BIND 8.2.2 problem

Brian Keves - NCS UAI Contractor keves at synopsys.com
Fri Apr 28 00:00:14 UTC 2000


Boy, guess I should get my asbestos underwear. Received 2 flames almost
immediately. Sure struck a nerve here. :-)

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

It is if no one looks at it. Strictly an internal problem I know,
we just don't have resources to do this stuff manually. Will need to
put in something to monitor this and page someone.

>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.

I understand it is illegal and the data shouldn't be in the zone. I
wish we lived in a perfect world, but unfortunately we don't. There
are circumstances in large companies with large domains that we
don't always control. Illegal data is one of those. 

I'm still trying to get rid of underscores in hostnames. And don't
even mention DHCP name conflicts.

>    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.

I'm still having a problem with the "throw the baby out with the bath water
philosophy" on this issue. The authors of BIND have provided other backward
compatibility options (fake-iquery yes; multiple-cnames yes; check-name
master ignore; etc...). Why not something like reject-on-errors no;?

> From Kevin Darcy
> I don't think this is silly at all. How can BIND trust the rest of your zone 
file
>if it contains such a glaring error? How does it know it's not completely
corrupted?

One error does not a bad zone file make. BIND knows the rest of the file 
isn't corrupt because it analyzes it too. It doesn't just quit.

Bind 4.9.7 would report errors and throw them away, not the baby. Why
not a backward compatible mode for this too?

I guess the answer is to better ensure the data is accurate before it
gets to named now. No slouching around taking advantage of an easy server. :-)

Thanks for your feedback. 

Brian
--                                                                         --
Brian Keves                    E-Mail:   keves at synopsys.com
Senior Unix Architect          Phone:    +1.650.584.4461
Network Computing Services     Cell:     +1.650.333.1223 #112
Synopsys, Inc.                 Fax:      +1.650.584.4343
700 East Middlefield Road      WWW:      http://www.synopsys.com
M/S C-11                       Physical: C1.136A
Mountain View, CA 94043-4033   "Who is John Galt?" - Ayn Rand




More information about the bind-users mailing list