separation of authoritative and recursive functions on internal networks

[Heiko Richter]

Am 05.08.2015 um 16:18 schrieb Gary Carr:
> Hello,
> 
> I understand the importance of separating authoritative and recursive
> functions on public facing systems. How crucial is it on internal
> systems?
> 
> My clients today resolve against internal servers that do recursion
> and also hold authoritative secondary copies of important internal
> zones. I did see on the ISC KB that this is an acceptable
> configuration 'having determined that the benefit outweighs any risks
> associated with this policy."
> 
> The primary benefit as I understand it, is that in removing the
> authoritative function from the recursive systems and isolating it on
> separate hardware (with an ACL permitting only the recursive servers
> to use them), I decrease the attack surface. The recursive servers are
> now isolated from being vulunerable to attacks against the
> authoritative code base.
> 
> In my environment, the recursive function is important, but not nearly
> as important as the authoritative resolution of internal namespaces.
> Has this separation of function improved my security posture in that
> area? If we assume the internal environment is hostile, an attacker
> now simply has to launch their authoritative-busting code against the
> authoritative servers rather than the recursive servers, forging the
> source as the recursive servers? The end result is the same in either
> design - an outage for critical internal functionality.
> 
> What are the downsides? Is it a stretch to say that this design might
> actually introduce security concerns? For example, if the
> authoritative function is moved, and the clients are left pointing at
> na now recursive-only server- that recursive server is now
> theoretically vulnerable to cache poisoned records for those critical
> internal namespaces, where as previously that was impossible because
> it was answering them authoritatively?
> 
> Does this design potentially weaken operational stability? By breaking
> out the authoritative functions on to unique hardware, we've now
> introduced a second place in the service delivery chain where a
> failure will be catastrophic to business function?
> 
> Overall, is breaking this function out - internally - really worth it?
> 
> Thoughts and comments appreciated
> 
> Cheers!
> 

Hi!

It all depends on the overall design of your network.

Of course there is a chance of somone attacking your authoritative
nameservers. But that chance can be greatly reduced by other factors:

- Do you only have company-controlled workstations where "normal" users
have no root privileges or does your company employ a BYOD prolicy where
everyone can bring their notbook, including the malware that is on it?

- Do you have a security software that doesn't only look for viruses but
also for software capable of such atacks? Often distributed as "security
software" helping the administrator to do vital test... ;-)

- Do you have a network security policy like port security on your
switches that prohibits attaching private devices that one could use for
attacks?

- Do you have a firewall between the servers and the clients? If not, is
there at least a router between them, so a potential attacker can't
resort to the very basic attacks such as mac spoofing?

- Do you have enough redundancy that taking a server offline will not
affect your network?

- And of course the very basic question: Does your Bind run with the
latest security fixes or are there gaping holes in it because you prefer
the easy way of installing a pre-built package?

The list goes on and on; so you see keeping the authoritative
nameservice on seperate machines is just a tiny bit of a much larger
picture. Having dedicated servers for authoritative service will only
enhance your security if you can really make sure nobody but the
resolvers can reach them.

Otherwise in my oppinion it is just a wast of time and money to seperate
authoritative and resolving servers on an internal network. I would keep
the two services together and focus on making sure nobody is attacking
the servers you have.

Also if you really want to outsource somthing to another machine, I
would first look into using views to create a stealth-master-solution.
Seperate that hidden master into another network segment that is only
reachable from the "normal" nameservers. Also use DNSSec inline-signing
to let your master sign your zone on-the-fly to ensure authenticity of
the answers your resolvers/slaves send out.

The only thing you should definitely seperate from your internal
nameservers are the public ones facing the internet (if you have any).

Yours,
Heiko