Bind V9 and hosting lots of Domains

Kevin Darcy kcd at daimlerchrysler.com
Wed Mar 1 23:02:23 UTC 2000


Mike Dimmick wrote:

> "Cricket Liu" <cricket at acmebw.com> wrote in message
> news:02bf01bf75a2$65bb7900$b577a8ce at boulder.acmebw.com...
> > > > It's being thought about along with trickle loading.  However
> > > > you just can't leave zone loading forever with secondary zones
> > > > as you need to get values out of the zone for its maintenance.
> > >
> > > Sorry, can you be more specific about what maintenance is required ?
> >
> > You don't want to wait three hours to load a slave zone's backup zone
> > data file and find out that the refresh interval for the zone is an
> hour.
>
> Well, yes, but there's another consideration at this point that I can
> see:
>
> Why has it taken three hours for the slave zone to be loaded?
>
> The answer to this is, of course, that no client has requested data from
> the slave zone.  And if no client has requested data, does it really
> matter that the slave zone is out of date, SO LONG AS the correct data
> is fetched in order to satisfy the query.
>
> 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.


- Kevin




More information about the bind-users mailing list