"Hidden Master" visible slave

Kevin Darcy kcd at daimlerchrysler.com
Wed Jan 11 22:26:25 UTC 2006


carcarx at hotmail.com wrote:

>No, it's not a big-budget Chinese kung-fu movie. ;-)
>
>We want to set up a DNS server for departmental administrators to
>maintain
>their own zones, but not "mess" with our primary nameservers.
>
>Our idea is to have that "departmental" nameserver master some zones
>with our primary nameservers being the slaves for those zones, but
>we don't want the departmental server to be visible to the internet.
>
Well, you can hide the *contents* of the departmental zones from 
Internet clients, just by putting allow-query restrictions on them. If 
you want to hide the fact that the zones exist, however, then that 
requires a little more work. The "proper" way is to maintain two 
different versions of your DNS in parallel -- the internal version, 
which would have those subzone delegations in it, and the external 
version, which wouldn't.

>Since the authoritative server for those zones won't be visible the
>clients should look to the visible ones (with some delay).
>
I assume what you're describing here is publishing a mixture of 
Internet-reachable and non-Internet reachable nameservers in your zones. 
That may _work_, but it's a really messy and kludgey way to go about 
things. Really, you shouldn't be publishing internal nameserver 
information to the Internet.

>Any docs about how to automatically avoid referrals to the departmental
>server (aside from tcp/ip rerouting trickery).
>
Not sure I understand what you mean by "referrals" in this context. 
Since your "primary nameservers" in this case are slaves for the 
subzones, they'll be sending back "real" responses or REFUSED responses, 
depending on your allow-query settings. Referrals would only come from a 
nameserver that was non-authoritative for a particular zone, but 
authoritative for one of its ancestor zones (e.g. a TLD server when 
queried for www.<something>.<TLD>).

Perhaps instead of "avoid[ing] referrals", you meant just selectively 
suppressing certain NS records from responses going back to the Internet 
(??). BIND has no such ability to "edit" responses arbitrarily on the 
fly, although the "minimal-responses" option at least suppresses *all* 
NS records in the cases where they are not mandatory. I don't think that 
covers all cases though; you could still get some "leakage".


                                                                         
                                                   - Kevin




More information about the bind-users mailing list