So... without stub zones, you know the drill: your local resolver follows
delegation, starting from the root nameservers. Delegation happens, and
life is good. If you're running views, then things work fine as well: your
view just needs to be configured to allow queries from your local resolvers.
In message <1401739377.33916.yahoomail...@web163502.mail.gq1.yahoo.com>, Nex6|B
ill writes:
>
> recently, a question came up about "stub" zones came up and what they are
> and are they part of the DNS standards or are they a good idea. i said,
> they are evil and should not be used if you can avoi
The typical use case for a stub zone is where the delegation chain is
broken, or incorrect, but you don't want to incur the overhead of
slaving the zone (or some other sort of bureaucratic snafu like the
owner/admin of the zone not letting you do zone transfers).
As a general rule, stub zones
I guess, i am having issues with this(maybe i am not fully getting it), and yea
I know large environments sometimes have multiple sets of name servers.
sometimes department level (i have this issue in my shop its a damn mess)
if all the zones are delegated properly the local resolver will query
Not quite, Bill. You point the zone at a different name server, but
_your_own_nameserver_ still does the iterative queries to make things
happen. It just queries a different set of nameservers than would
happen through normal delegation.
The only recursive query going on is from the client t
recently, a question came up about "stub" zones came up and what they are and
are they part of the DNS standards or are they a good idea. i said, they are
evil and should not be used if you can avoid it. they way I understand them is
the are when you create local zones for zones you are NOT aut
6 matches
Mail list logo
