Bind V9 and hosting lots of Domains

[Kevin Darcy]

Mike Dimmick wrote:

> "Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
> news:38BDA17F.408156A0 at daimlerchrysler.com...
> > Mike Dimmick wrote:
> >
> > > I admit that zone transfers take quite a bit of time, but what's to
> stop
> > > the secondary asking its primary for the *specific* information that
> the
> > > client requested, or referring the client to the primary while
> fetching
> > > the updated zone from the primary?
> >
> > Just grab the information from the primary on-demand, eh? What if it
> > happens to be down when the client asks? Then you either have to
> answer
> > with old, possibly out-of-date data, or you have to tell the client
> that,
> > even though you are authoritative for the zone, you can't resolve the
> > query. Neither of those is acceptable, nor is just referring the
> client to
> > the primary (stub resolvers won't be able to use the referral anyway).
> Part
> > of the responsibility of being a slave is to try to keep your copy of
> the
> > zone as current as possible, according to the refresh and retry times
> in
> > the SOA record. What you are suggesting is an abdication of that
> > responsibility.
>
> Oops, should have marked with *newbie alert* or some such :(
>
> Sorry, I didn't think this through before posting.  Thanks very much for
> clarifying the situation.
>
> Perhaps just fetching enough glue from the zone file (Start of
> Authority, NS records, A records for the zone) would be OK -- but in
> order to be in any way efficient, you'd have to ensure that the
> necessary records would be at the top of the file.

Okay, that might help you load large zone files faster, but I think most of
the slow-loading problems come from sites that host many thousands of tiny
zones, and in that case it doesn't help very much, if at all.

> What I'm not sure of in the design for BIND is the use of *text* files
> to carry the stored zone information.  Yes, I know the RFC does specify
> the format of zone files (which improves distribution of zone files
> between servers),

The RFC does specify a "master file format", but I don't believe it
actually mandates that servers use this format to store zone data. I think
the only reason BIND through version 8 still uses a slightly-larger
superset of that format ($TTL and $GENERATE directives, for instance, were
added to the RFC specifications) is because most admins were familiar with
that format and the costs of  trying to hack other formats into the
codebase were judged to outweigh the benefits.

> but surely it's less often that an admin will look
> directly at the stored zone file?  A direct binary dump of the database
> would seem more logical to me, with an additional tool to convert to
> text format if a human does need to read the info, or to export to a
> different name server package.

BIND 9, a total rewrite of BIND, currently in early beta, promises a
variety of backend datastores. Check out
http://www.isc.org/products/BIND/bind9.html

> If the daemon is taking a long time to start up *because* it's having to
> parse these text files and convert them to a different internal memory
> format, it seems sensible to store them in something closer to the
> internal format.  Cf sendmail.

If you're talking about frozen configuration files, I believe sendmail
stopped supporting those a while ago. They were a pain for admins to deal
with and didn't really buy any performance improvements on modern machines.
At least, that's what Eric Allman told me, but what does he know? :-)


- Kevin