Secondary queried?

Mark Damrose mdamrose at elgin.cc.il.us
Thu Mar 7 18:28:31 UTC 2002


"Smithz" <mav102 at hotmail.com> wrote in message
news:a6855m$qr8 at pub3.rc.vix.com...
>
> With primary and secondary I mean authoritative for the zone.  Thank
> you for the explanation of stub and full resolver.  The remaining
> question I have is this scenario.  Lets say a "stub resolver" queries
> their ISP name server for a domain that it does not have local or
> cached knowledge for that domain and does not have a forwarder
> configured.  At this point the queried name server looks to the
> primary authoritative name server of the domain.  If the primary does
> not have the zone configured, will the name server making the query
> bother to check the secondary authoritative name server or will it
> give up and say "domain not found"
>
> If this is not how it works please set me straight

It depends.  First of all the servers are not queried in order.  Some name
servers will contact the primary first, other will contact the secondary
first.  Those designations are only important to you - primary is where you
maintain the data, secondary copies from primary.

If a listed name server is not available (shutdown, link down, etc) the
ISP's servers will try other listed servers.
If a listed name server is not configured (lame) the ISP's servers will try
other listed servers.
If a listed name server is configured but there is a configuration error it
will return a SERVFAIL message and no further servers will be tried.

>
>
> Kevin Darcy <kcd at daimlerchrysler.com> wrote in message
news:<a66gq1$h4h at pub3.rc.vix.com>...
> > Exactly how are you using the terms "primary", "secondary" and "client"?
> >
> > A "stub resolver" (which is how most PC-class devices are configured)
> > will typically work through a statically-configured (sometimes
> > DHCP-supplied) list of nameservers until it gets some sort of answer. It
> > doesn't know or care whether the answer comes from the "primary" or
> > "secondary" nameserver for the zone, or even (as it usually does) from a
> > nameserver which isn't even authoritative for the zone.
> >
> > On the other hand, a *full* resolver will try all nameservers for a
> > particular zone before it gives up on a query. Again, it doesn't know or
> > care whether the nameserver it queries for a zone is "primary" or
> > "secondary", but it *does* care whether the answer is marked as
> > authoritative or not (if a delegated nameserver answers with
> > non-authoritative responses, this is the condition known as "lame").
> >
> > Finally, you brought up the topic of forwarding. Forwarding overrides
the
> > normal algorithm that a full resolver uses to obtain information about a
> > zone. Sure, you could point your "forwarders" at both a "primary" and a
> > "secondary" nameserver for a particular zone, in that order, but why
> > bother? If you don't forward at all, and the "primary" nameserver is
> > unavailable, your nameserver will get around to asking that
> > "secondary" nameserver anyway, assuming that it is actually a
> > *published* nameserver for the zone (as opposed to being what is called
a
> > "stealth slave"). So forwarding doesn't really buy you anything here.
All
> > it does is force your queries to go the "primary" nameserver, assuming
> > it's available, which may not be the optimal path. Far better to let
> > named figure out the "best" nameserver instead of forcing it to always
> > use a particular one.
> >
> >
> > - Kevin
> >
> >
> > Smithz wrote:
> >
> > > In the case that the primary name server is available but does not
> > > have the zone configured will the client making the request make an
> > > additional request to the secondary name server as it could possibly
> > > have a valid zone file still available the ability to resolve the
> > > request?
> > >
> > > If the answer is NO would it be acceptable to include the secondary in
> > > the list of forwarders giving the primary the ability to ask the
> > > secondary during the time the secondary has the correct information?
> > >
> > > Thanks in advance!
> > >
> > > Ed
>




More information about the bind-users mailing list