Authoritative Redundancy

[Baird, Josh]

Would there be any benefit in assigning them as additional master's for all of my zones (in addition to DNS01), or would this just complicate the entire environment?
 
Thanks


In article <mailman.1534.1274300384.21153.bind-users at lists.isc.org>,
 "Baird, Josh" <jbaird at follett.com> wrote:

> Hi,
>
> I currently have three authoritative servers in the RRset for my
> internal zones:
>
>         NS      dns01.blah.com.
>         NS      dns02.blah.com.
>         NS      dns03.blah.com.
>
> DNS01 is the sole master for my internal zones.  I have a number of
> resolving DNS servers throughout my environment that contain slave
> definitions for my internal zones to override recursion.  These slave
> definitions use DNS01 as their master (only DNS01, not DNS02/03).
>
> zone "example.com." IN {
>         type slave;
>         masters { DNS01's_IP_ADDRESS; };
>         file "hosts/slaves/example.com-hosts";
> };
>
> DNS02 and DNS03 also contain slave zones for all of my internal zones.
> Their master is also DNS01.
>
> My question is.. am I gaining anything by having DNS02/DNS03?  With
> DNS01 being my sole master, it doesn't seem like DNS02/DNS03 are
> providing any additional benefit.  How could I make a better use of
> DNS02/DNS03?  Recursion is disabled on them, and no clients directly
> query them; they query the numerous resolving DNS servers throughout the
> environment.

I think you can safely get rid of them.  With all your internal
resolvers running as stealth slaves for your zones, you don't need
published slaves.  NS records are only used by recursive servers.

--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100519/44d7f1bf/attachment.html>