Potential problem.

Marc Thach Xuan Ky marc.thach at tesco.net
Tue Dec 4 14:42:32 UTC 2001


Justin,
Other nameservers will cache all your four (if Z is included then I'd say it
isn't actually hidden) NS records, but will tend to use those from which they
receive a fast response, so it will be less than two out of four failing.  Even
when they get no response, they will try another one four seconds later.  That's
the "official" view, however I'm yet to be convinced that there is not a
weakness in the algorithm used which will make this rather worse (if you're
interested have a quick look in the archives).  If I were you, I'd be wanting to
transfer two separate views of your namespace to your internal and external
servers instead.
rgds
Marc TXK

"McNutt, Justin M." 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.
>
> 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?
>
> Later...
>
> Justin McNutt
> Network Systems Analyst - Expert
> DNPS, Mizzou Telecom
> (573) 882-5183
>
> "It's a kind of magic."
>
> "There can be only one!"



More information about the bind-users mailing list