"Hidden Master" visible slave

[Kevin Darcy]

Barry Finkel wrote:

>"carcarx at hotmail.com" <carcarx at hotmail.com> wrote:
>
>  
>
>>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.
>>
>>Since the authoritative server for those zones won't be visible the
>>clients should look to the visible ones (with some delay).
>>
>>Any docs about how to automatically avoid referrals to the departmental
>>server (aside from tcp/ip rerouting trickery).
>>    
>>
>
>Kevin Darcy has already responded, but I think that he is misreading
>your request, or reading too much into it.  But I may be wrong.
>
>Make your departmental name servers hidden; do not put their names in
>NS records.  Slave those zones on your name servers, the servers listed
>in the NS records.  When any departmental zone is updated, the DNS
>NOTIFY process should cause a quick reload of the changed zone on the
>slave servers, which your clients will be using for DNS resolution.
>Also, if you do not want people querying the departmental name servers,
>then do not include those servers in the TCP/IP definition
>(i.e, resolv.conf) on the client machines.
>
>I do not see anything more complicated here, such as departmental
>nodenames that you want hidden from the Internet.
>
Barry,
            If the NS records for the internal, departmental nameservers 
are missing from the relevant zone(s), then how can you ever run a 
caching-only config on an internal resolver, without giving it access to 
the Internet-facing nameservers, which may not be feasible/manageable 
because of routing restrictions, firewall rules, etc. and creates a 
perhaps-undesirable dependency between your internal infrastructure and 
your Internet-facing infrastructure?

At a certain critical mass, rather than maintaining "special" 
configurations in all of one's internal resolvers, it makes more sense 
to bite the bullet and just implement a split namespace. Then one can 
put whatever NS records, or other kinds of records one wants in the 
internal zones, without worrying about any consequences for Internet 
clients. It's actually quite liberating. Until one reaches that critical 
mass, though, the time and effort required to set up a parallel 
maintenance regime, is not worth the long-term benefit of a clean 
separation.

                                                                         
                                             - Kevin