[lug] DNS upgrade

[Nate Duehr]

The syntax parser for zone files got a lot more strict about both
location of parenthesis (follows the RFC now, parens belong at the END
of a line to indicate that there will be another line following), and
the use of Glue records.  (Glue records without appropriate supporting
records will actually cause a zone load failure instead of a warning as
they did in 8.2.2.)

The output of your /var/log/messages when you do an ndc restart or ndc
reload <zonename> (or wherever you log to) would be helpful to us if you
need further help.

This caused a few zone failures for me on a rather large DNS server.
Most were the hand-created ones and not ones generated from scripts,
etc.  Yep, I got bit by the parenthesis thing and didn't notice the
error message (or think to grep for failures... lesson learned) on a big
server with lots of zones.

The only other MAJOR complaint I have with 8.2.3 is that a lot of the
error messages are LESS verbose than they used to be.  For example if
you find if a zone's not loading, you may or may not get WHICH zone in
some cases, especially the Glue record messages.  That's highly
annoying.

The fact that they made the thing more strict and didn't warn anyone
leads me to believe they lost control of their release process or were
rushed horribly by the exploit that was published.  The Nominum folks on
the bind-isc mailing list have been typically "superior" about the whole
thing, contending that since BIND is a reference implementation, it
should have been following the RFC rules for zone files all along, but
offering no explanation or apologies for making it more picky with LESS
error information.  Typical of them.

Hopefully this helps, sorry it turned into a rant.  I'm also annoyed at
this new "consortium" they're proposing for security announcements.  Pay
money and sign an NDA to get early access to bug information?  Come on.
My hope is that those who find the bugs scream them loudly from the
rooftops and are not gagged by their company having an NDA now with ISC.
Argh.

And even though he's a complete jerk about it, DJB's comments about
"none of the root servers are running BIND 9 yet, are they?" are pretty
valid.  Nominum is using a lot of people as guinea pigs for a version
that is a COMPLETE re-write from the ground up.  BIND 9 isn't BIND at
all, really.  It should have been called something else.

The good news is that Cricket Liu already has the 4th (!!!) Ed. of DNS &
BIND in production and soon to print at O'Reilley... with BIND 9.1.0
info in it -- finally!  Yay...  go Cricket!

I'll stick with BIND, but I'm sure keeping a watchful eye on djbns and
other "products" out there... on the flip side, I think some diversity
in name server code would be good.  Security risks that attack the BIND
could affect an awful lot of servers out there right now.


On Wed, Feb 14, 2001 at 02:38:10AM -0000, Stephen G. Smith wrote:
> After upgrading my bind to the newest .RPMs I have a bit of trouble.
> I have 40 domains and all still work but one.
> The world seems not to be able to see it..
> When I use www.dns411.com
> I get the following output.
> 
> Reverse lookup produced no results.
> The IP number MYDOMAIN.COM
> does not appear to be inverse-mapped to a domain name.
> Please click here to use swhois
> To find the owner of the IP block.
> 
> Very strange, I have two other domains that point to the same IP
> with the exact same zone files and named.conf entries. as the
> domain in question.
> Whois reports correct.
> 
> Any ideas what could have changed?
> Sound like something changed upstream?
> 
> Thanks for any help..
> 
> Stephen
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

-- 
Nate Duehr <nate at natetech.com>

GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2
Public Key available upon request, or at wwwkeys.pgp.net and others.