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