Bind V9 and hosting lots of Domains

Mike Dimmick mike at dimmick.demon.co.uk
Thu Mar 2 17:50:46 UTC 2000


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

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

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.

--
Mike Dimmick
Studying BSc Computing Science, Aston University, UK.





More information about the bind-users mailing list