I'm designing DNS service for a network and had a few architecture questions. The O'Reilly/ Cricket Liu DNS book and the NIST DNS security guide don't address these questions except in a very general way.
Here is the proposed network, which has internal (RFC 1918 space) and DMZ segments (with multiple servers, not just DNS servers) as well as mail and www servers at an outside colo. The DNS servers are the blue boxes:
Here are the requirements:
- DNSSEC support
- On the internal networks, delegation to internal zones in RFC 1918
space - Separate authoritative and recursive servers
- Hidden master (aka hidden primary) allows zone transfers to slaves but resolves no requests
- All nameservers run chrooted (the default with Bind on FreeBSD)
Here are my questions:
-
Is there anything obviously broken about this design?
-
Are there any missing or extraneous elements here?
-
OK to run the hidden master on the same subnet as the internal slave servers?
-
Given relatively light DNS traffic (< 1 Mbps) on the internal and DMZ networks, are there security issues to running the caching-only servers in jails (BSD-speak for VMs) on the authoritative servers? Or should they be on dedicated machines?
Thanks in advance!
Best Answer
Nothing is Obviously wrong. .. At least that I can see.
Missing: Are you comfortable not having a hot stand by for your hidden master? The system seems quite engineered (I don't want to call it over engineered without seeing your use case) to rely on a single primary host. It's outside the scope of your diagram, but do your have a contingency plan for when [not if] the primary master blows up?
Extraneous: Keep in mind that every dns server that you add to the mix is another server that must be managed. Given your usage, is it critical to have this many DNS servers?
I would expect the hidden master, and authoritative dns slaves to be in the dmz. Lock down the master appropriately. The internal slaves are answering authoritative look ups for your zone from the internet correct? If the internal slaves only answer queries for your zone from internal hosts, you either need a HUGE zone, a silly number of internal lookups to your internal zone (consider caching DNS servers at the host/workstation level), or you have given too much horse power to internal DNS. If they are answering queries from the internet, I would expect them to be in the DMZ. You are free to label them how you want.
As far as the master being on the same subnet as the slaves - Lock it down. Should not be an issue (and will save you some routing overhead come zone xfer time).
Yes. There are always security issues. If the internal caching only servers are locked down to accept only traffic from internal sources, they are placed in jails, on a presumably BSD environment, and updated and monitored regularly... A hacker has a lot of work to do to exploit the environment.
Your biggest risk (See: not a professional risk analyst) is likely the chance of a hacker, by a stroke of shear miracle, is the possibility of having one of your authoritative DNS slaves get hijacked. Likely to result in partial defacement, or if the attacker is truly brilliant, some 'poisoning' and information theft (See: SSL/TLS to put a halter on that).
Next biggest (See: not a professional risk analyst) is the corruption of the slave OS requiring re-install/restore.
Ultimately:
It's a fairly solid design, and without a view into the network (which you'll not be expected to provide us), it is quite hard to find shortcomings / faults with the design. The only thing that clearly stands out is that: there are a lot of pieces, a complex setup, and a lot of engineering here... Make sure that there is a business for it.
Ex: You could run Bind9 as an Authoritative Slave, that does recursive/forwarding lookups, and caching all in one daemon. (and saves multihoming / port forwarding / other networking magic to get two DNS daemons answering on the same box).