Fake root with selective forwarding

[Kevin Darcy]

William Stacey wrote:

>Sorry to be thick here, but just verifying:
>
>Assuming ForwardFirst and not root server.
>1) If any forwarders are add to slist, then would NS delegation records even
>be added to slist?  
>
Not unless the forwarding fails.

>How about root hints?
>
No, root hints are only used for the "priming" (root NS) query that 
named makes when it starts up. After that, it'll have cached root 
information, and during the course of resolving queries, cached NS 
records for subdomains below that. It'll use those cached entries. 
AFAICT, the "safety belt" idea has been discarded, since there was too 
much ambiguity between "safety belt" data and regular cached data. So 
the nameserver "primes" instead, populates its cache, and therefore has 
no need of a "safety belt" after that.

>2) If true, then for ForwardFirst: All forwarders are added to slist, any
>delegations NS are added, and all root-hints are added.  So forwarders are
>tried first, then delegations, then hints in that order?
>
Forwarders first (as the name implies :-), then, if the forwarding 
fails, it'll act as if the forwarding never existed, using either cached 
referral information or authoritative data, depending on which is 
closer, hierarchically speaking, to the name being looked up. If a 
server has forward first for a.b.c.d.com, for instance, and forwarding 
fails for a name in that domain, then even if that server is 
authoritative for d.com, it would still use cached referral information 
for b.c.d.com, if any, in preference to c.d.com delegation records, 
since the cached information is closer to the target name. The "spirit" 
of the resolver algorithm is to always get closer and closer to the 
target name, i.e. "down" the hierarchy, until you get a definitive 
answer or you can't go any further and have to give up. Generally 
speaking, then, if you have "closer" referral information in memory, 
you'd never go "above" that point in the hierarchy, and never to the 
root except as a last resort. All of this logic, including the 
forwarding enhancement, is contained within Step 2 ("Find the best 
servers to ask") of the RFC 1034 algorithm.

>3) If no forwarders are added to slist (either not configured or set to
>"{}" ) then any delegations are added to slist if available and all
>root-hints are added and tried in that order?
>
Well, if forwarders are set to "{}", then presumably the zone is defined 
as some type other than "type forward", e.g. stub, master, slave. In 
which case it will have NS records for the zone itself (authoritative NS 
records in the case of master or slave, non-authoritative NS records in 
the case of stub), and won't need to rely on delegation records from an 
ancestor domain.

                                                                         
                                                   - Kevin