Re: [cobalt-developers] publishing slave nameservers was RE: Denial-of-Service Vulnerabilityin ISC BIND 9

[Jeff Lasman <jblists@xxxxxxxxxxxxx>]

Matthew Nuzum wrote:

> Jeff, have you ever experienced a problem with this?

Not so far; still checking <smile>.

> We tried something
> similar to this and had problems with RoadRunnerwho is a large ISP in
> our area. (possibly effects other ISPs as well).  They use some caching
> DNS software for their customers and it wouldn't resolve DNS requests
> for domains where the server answered as non-authoritative.

Here's what the cricket book ("DNS and BIND, by Paul Albitz & Cricket
Liu, published by O'Reilly) says about non-authoritative answers:

"What is happening is that the first time the local name server looks up
slate [their example domain], it contacts the name server for
mines.colorado.edu [again, their sample], and the mines.colorado.edu
server responds with an authoritative answer. The local name server, in
effect, passes the authoritative response directly back to nslookup. It
also caches the response. The second time you look up slate, the name
server answers out of its cache, which results in the answer
'nonauthoritative.'"

So what does this mean in english?

It means that YOUR primary and secondary nameservers will always answer
authoritatively for their own domains, but will only answer
authoritatively for domains it looks up recursively if those domains are
NOT already in it's cache.

How do you make sure your nameservers always answer authoritatively?  By
making sure you have NS records in the zone file for them, by making
sure they've got a secondary entry in their named.conf files, and by
making sure they can reach the master nameserver to get the zones
transferred.  Getting the zones transferred through a firewall is the
hard part <wry grin>.  We cheat <smile>... our local slave sits across
the firewall and it's named.conf file has the private IP# of the master
server, while the other slaves' named.conf files have the public IP# of
the first slave (the one straddling our firewall.

Yes, I know about the problems and security holes... that's why we've
not yet fully implemented this, but it does seem to work in our tests so
far.

> It was a very odd problem and difficult to diagnose.  We tested it on
> only a couple of domains but we were able to see problems right away.

How were you telling the slaves they were authoritative, and how were
you transferring zone-files to them?

> Is there a trick to making the slave servers answer authoritatively?
> That very well could have been our problem.

I think I just wrote it up above <smile>.

> It's kind of a moot point, as I decided to outsource my DNS and can't be
> happier.

Outsourced DNS has been one of our products for years now <smile>.

Jeff
-- 
Jeff Lasman <jblists@xxxxxxxxxxxxx>
Linux and Cobalt/Sun/RaQ Consulting
nobaloney.net
P. O. Box 52672, Riverside, CA  92517
voice: (909) 778-9980  *  fax: (702) 548-9484