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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users