Mark,
Thanks much for clearing this up ! I get it now -- the lookup
algorighm is opportunistic, and starts below the root if the right NS
records are already in cache. Having stub zones insures that is always
the case -- very cool !
Also thanks to everyone else who responded !
--Gabriel
On Tue,
In message <20100302003617.ga27...@foober.net.cmu.edu>, "L. Gabriel Somlo" writ
es:
> Kevin,
>
> > For redundancy, you might want to consider slaving ".local" and
> > "example.com" on the remote servers. Note that you don't need to
>
> Thanks for the reply ! I am slaving and/or stubbing some o
In article ,
"L. Gabriel Somlo" wrote:
> Kevin,
>
> > For redundancy, you might want to consider slaving ".local" and
> > "example.com" on the remote servers. Note that you don't need to
>
> Thanks for the reply ! I am slaving and/or stubbing some of our zones
> in some instances, and redund
Kevin,
> For redundancy, you might want to consider slaving ".local" and
> "example.com" on the remote servers. Note that you don't need to
Thanks for the reply ! I am slaving and/or stubbing some of our zones
in some instances, and redundancy is not what I was concerned about.
I am simply loo
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 ca
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
6 matches
Mail list logo
