Potential problem.

Barry Margolin barmar at genuity.net
Tue Dec 4 16:33:51 UTC 2001


In article <9uil8n$juo at pub3.rc.vix.com>,
McNutt, Justin M. <McNuttJ at missouri.edu> wrote:
>
>I'm working on changing the layout of our name servers so that they work
>like this:
>
>Name server Z is the hidden master.  Lives behind a special firewall.
>Accepts no name queries.  Accepts zone transfer requests only from name
>servers A-D.
>
>Name servers A and B are listed in the WHOIS database and are connected to
>the enterprise DMZ (outside the enterprise firewall).  Accept queries from
>anywhere and accept relayed queries from name servers C and D.  Servers A
>and B are slaves to server Z.
>
>Name servers C and D are connected inside the enterprise firewall and accept
>queries only from internal users.  Relay is enabled.  All queries for 'new'
>stuff are relayed to servers A or B.  Servers C and D are slaves to server
>Z.

What is "relay"?  The word used in BIND configuration is "forwarding", is
that what you mean?

>The enterprise firewall blocks any name queries in both directions, except
>traffic among the five servers.
>
>Potential problem:  All five name servers will need NS records for
>themselves, right?  If so, won't external name servers cache that and
>attempt to round-robin queries among all five, and thus fail three out of
>five queries?

No.  You usually only need to list nameservers that are usable from the
public Internet in your NS records.  Servers C and D are queried due to the
resolver configurations on the internal client machines, not NS records, so
NS records aren't needed.

However, to ensure that C and D are updated quickly when the zone changes,
you should put their addresses in Z's "also-notify" option.  By default Z
will only send NOTIFY messages to the servers listed in the NS records.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


More information about the bind-users mailing list