forwarders{} and delegation in zone behavior.

[William Stacey]

In 1034, it does not appear to say, but I assume Step 1 in the resolver
logic also follows any cnames before returning?  TIA

"Step 1 searches the cache for the desired data. If the data is in the
cache, it is assumed to be good enough for normal use.  Some resolvers
have an option at the user interface which will force the resolver to
ignore the cached data and consult with an authoritative server.  This
is not recommended as the default.  If the resolver has direct access to
a name server's zones, it should check to see if the desired data is
present in authoritative form, and if so, use the authoritative data in
preference to cached data."

-- 
William Stacey

"William Stacey" <staceyw at mvps.org> wrote in message
news:c7b6ui$ue7$1 at sf1.isc.org...
> If you have a "forwarders { 1.1.1.1 }" statement in your options, you need
a
> "forwarders {}" in a zone to override the global forwarders to follow NS
> delegations in that zone instead of using global forwarders (I think).  I
am
> unclear how to jive that with the 1034 basic algorithm for a rd query.
> Assuming you have an auth zone configured (e.g. domaina.com), should not
> step 1 find the qName in domaina.com or in any delegations and return
result
> or nxdomain even before it would try forwarding logic?  Or how might you
> clear up algorithm below (for my understanding) to include the forwarders
> behavior - maybe it is in there and I do not see it.  Thank you for your
> insight.
>
> "5.3.3. Algorithm
>
> The top level algorithm has four steps:
>
>    1. See if the answer is in local information, and if so return
>       it to the client.
>
>    2. Find the best servers to ask.
>
>    3. Send them queries until one returns a response.
>
>    4. Analyze the response, either:..."
>
> -- 
> William Stacey
>
>
>