Shortcut the lookup algorithm *other* than via 'forward' ?

[Kevin Darcy]

The "hints" file is a non-starter -- for years now it's been limited to 
only containing root-zone-related information.

For redundancy, you might want to consider slaving ".local" and 
"example.com" on the remote servers. Note that you don't need to 
*publish* those servers in NS records: they can be so-called "stealth" 
(unpublished) slaves. Being "stealthed" will prevent them from receiving 
queries for names in the domain from iterative resolvers everywhere in 
the network. These days you don't need to worry very much about 
zone-transfer overhead either, unless the zone changes frequently, since 
incremental zone transfer (IXFR) is the default.

If you don't need the redundancy and/or are concerned about the overhead 
and/or if the authoritative nameservers don't/can't allow zone 
transfers, you could use "type stub" instead.

Note that if you have forwarding defined globally, you'll need to 
specify "forwarders { };" in the relevant slave/stub zone definitions in 
order to disable forwarding for those respective parts of the namespace.

                                                                 - Kevin

On 3/1/2010 3:52 PM, L. Gabriel Somlo wrote:
> Hi,
>
> I am looking for a way to start the DNS lookup algorithm somewhere
> further down the tree, instead of at the root, but only for a small
> specified set of domains.
>
> I have a relatively large/complex DNS installation, where we run
> our own .LOCAL TLD mapped to RFC1918 IP space. Various departments
> and business units have their own authoritative name servers for
> subdomains within that space, and we delegate to them from our
> primary authoritative name server. This primary name server also
> holds our public authoritative data, also with delegations of (some)
> third-level subdomains to authoritative name servers run by
> the aforementioned departments and business units.
>
> I currently run dedicated caching servers (available only to
> internal clients), which are configured to forward anything within
> *.local and *.example.com to our primary authoritative server. The
> latter must currently recurse (at least) for the caches, since it's
> not guaranteed to be authoritative for all subdomains of *.local and
> *.example.com, but is still expected to return a full answer as a
> 'forwarder' configured in the caching servers' named.conf.
>
> What I would like to do instead is to modify the root hints on the
> caching servers by adding
>
> LOCAL.                           IN NS primary-auth-server.example.com
> EXAMPLE.COM.                     IN NS primary-auth-server.example.com
> primary-auth-server.example.com. IN A  111.222.333.444
>
> so, rather than forwarding to 'primary-auth-server' they can simply
> begin their own lookup algorithm there instead of at the root servers
> (for *.local and *.example.com only).
>
> I tried modifying the root hints file on my caches as described,
> but BIND (9.6.1-P3) ignored my changes and kept starting the recursive
> lookup at the real root servers regardless.
>
> Any idea how I could make BIND do what I asked it to ?
>
> Alternatively, I'd also appreciate any insights into why what I'm
> asking for might be a very bad idea and shouldn't be done (or even
> supported at all in BIND) ! :)
>
> Thanks,
> --Gabriel
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>