Definition of a "hidden primary"

[Kevin Darcy]

Yes, you've got that all correct, although I wonder why you say "the DNS
databases on all servers are the same" -- if you're concerned about security,
wouldn't you want to expose only a *subset* of your namespace to the external
world, a so-called "shadow namespace"?

What you describe is basically the same as our setup, except that we only serve
a "shadow" namespace to the outside and for us Y and Z (the nameserver
instances resolving for internal clients) exist as separate nameserver
instances running on the same physical boxes as A and B, respectively, but they
only listen to internal and loopback interfaces. This is more economical than
having to scrounge up 4 boxes + a hidden master for DNS duties, although
arguably slightly less secure. All 4 nameserver instances run unprivileged and
chroot'ed of course. From a performance/capacity standpoint, remember that the
nameserver instances which serve the external world (A and B) can and should
have recursion turned off. This means that they experience no cache growth and
each can co-exist quite comfortably with a "private" caching nameserver
instance (Y or Z) running on the same box.


- Kevin

"McNutt, Justin M." wrote:

> Lemme see if I've got this straight, because it sounds like a good idea.
> I've finally got some management support to implement some halfway-decent
> security measures and I want to take full advantage of it.  :-)
>
> The "hidden primary" setup is where the root servers list two servers A and
> B as the "primary" and "secondary" name servers for the name spaces I
> control (I happen to have control over both the forward and reverse name
> spaces, fortunately).
>
> However, unbeknownst to the world, but knownst to us, servers A and B are
> configured as "slave" servers (via named.conf) and are actually pulling zone
> information from server X, which is configured as "master".
>
> (sounds like a soap opera)
>
> Only servers A and B have NS records in the DNS database, thus even though
> all information ultimately comes from server X, servers A and B are able to
> answer queries authoritatively and are the only servers visible to the
> Internet (assuming that server X is behind a firewall).
>
> Do I have the basic idea here, or is there a piece I'm missing?
>
> This is the environment I'm planning to bulid, with the extra stipulation
> that servers A and B answer queries from the outside world, but servers Y
> and Z answer queries for 'internal' users (hosts on my network).  If A
> and/or B are compromised, my internal users continue to function.  If Y
> and/or Z are compromised, services we provide to the outside world are not
> affected.  (Neither is really acceptable for an extended period, but it at
> least segments the user communities).
>
> Lastly, A, B, Y, and Z could *all* be compromised without jeopardizing the
> truly authoritative data on server X, who is the "hidden primary" (back to
> my original question).
>
> So first of all, do I have the definition of "hidden primary" correct?
>
> Second, assuming I have a zillion dollars and can build all of this, what is
> still missing?  Anything?
>
> Lastly, if servers A and B (listed on the root servers) *only* accept
> queries from the outside world and servers Y and Z (internal) *only* accept
> queries from internal users, am I going to run into problems?  Assume that
> all of the internal hosts have their resolvers configured to point to
> servers Y and Z via DHCP (which covers most of our users) and that the DNS
> databases on all servers are the same.
>
> Thanks for any suggestions!
>
> --J