Split roots (was: Can someone explain forwarders and why I don't need them?)

Simon Hobson shobson0211 at colony.com
Fri Aug 1 08:45:46 UTC 2003


Kevin Darcy wrote:

>  > It's only an advantage if you have multiple zones internally
>>  that require you to establish a private root and thereby a
>>  private, disjoint namespace -- but you still want to resolve
>>  Internet (or some other) namespace names.
>
>Okay, so how is it really a win to have to maintain all of those delegations
>in a private root zone (remembering of course that all delegations from a root
>zone require glue A records, so anytime the name or address of a delegated
>nameserver changes, so must your root zone),plus all of those so-called
>"synthetic" zone definitions, than it is to just maintain the equivalent
>number of stub-zone definitions and be done with it? I'm still not seeing the
>point of the configuration, other than as a Proof of Concept to show how
>egregiously you can abuse BIND's failover algorithms...

Well, in the situation I am in, we are looking at perhaps 20 
organisations, all with multiple DNS servers and at least one domain 
name each. By the time we have all built a mesh where we all have 
slave or stub zone declarations for every other domain, that's quite 
a lot of work, and an even bigger maintenance issue.

What we DON'T want to do is forward all our internal requests to (for 
want of a better name), and internal root server, as that would be 
inefficient. On the other hand, if we were to define this internal 
root server as master in our slave/stub declaration, we would be 
defining the zone differently to the 'real' SOA & NS records which we 
would fetch which I would assume would cause operational issues.


The problem I would have with Herbs setup is that every request we 
make (for domains we don't already hold NS records for) would go to 
the internal root servers first, and that rather defeats part of the 
object of having a split-root system - we could have achieved a 
similar effect by setting up a number of internal servers to which we 
forward ALL non-local queries, and let those servers resolve 
everything for us. This would centralise things in a manner we 
wouldn't be happy with.


So I suppose the question is, what is the easiest way to have a 
situation where we have a small number of internal 'root servers', 
and tell all our other servers "you can find the real servers for 
domains x, y, and z from these servers" ?

Would it cause problems if in my slave/stub zone declaration I give 
the masters as A and B (the 'internal root servers'), but when my 
server queries A or B, it gets NS records giving Y and Z (the real 
servers for the zone) as the name servers for the zone ?

If it worked and didn't cause problems, this would be enough for us, 
since it would allow us to define everyone elses domains in terms of 
just 2 or three servers which would not change very often. Anyone 
changing their DNS structure would just have to get these two or 
three servers changes, instead of all the organisations having to 
change their setups separately.

Bear in mind that while I run Bind, others use Netware or Microsoft 
(and I very much doubt if any of them would be prepared to consider 
changing).

Simon

-- 

NOTE: This is a throw-away email address which will reach me for as 
long as it stays spam-free, remove date for real address.

Simon Hobson, Technology Specialist
Colony Gift Corporation Limited
Lindal in Furness, Ulverston, Cumbria, LA12 0LD
Tel 01229 461100, Fax 01229 461101

Registered in England No. 1499611
Regd. Office : 100 New Bridge Street, London, EC4V 6JA.


More information about the bind-users mailing list