separation of authoritative and recursive functions on internal networks

[Darcy Kevin (FCA)]

"Separate authoritative and recursive functions" is really a simplistic approach to a complex challenge. I think a better approach is to make both the published-authoritative function and the recursive-resolution functions robust enough *in*and*of*themselves* so that there is no value to an attacker taking down a single node or instance for either function. At that point, it doesn't matter whether you mix published-authoritative with recursive, or not.

So how do you make the published-authoritative function robust? The main way is to publish a sufficient number of NS records, and potentially some or all of those are Anycast'ed (and/or potentially hardware-load-balanced) to even more nodes. (Don't go overboard on your NS records, however, since this can lead to TCP retries). Similarly, you can use Anycast and/or hardware-load-balancing to make the recursive-resolver function robust, and doing so has the added benefit of simplifying stub-resolver configuration throughout your enterprise. Another thing you can do is implement "stealth slave"s for your critical zones (which, by the way, doesn't violate the spirit of separating the functions, since the motivation for that advice pertains to *published* authoritative service, and, by definition, "stealth slave"s aren't published). Stealth slaves are more resistant to DoS (since they answer from data which is local) and have no cache to poison. There are (expensive) hardware approaches to mitigating DoS, as well.

As another poster mentioned, the physical security of your DNS instances - whether they be authoritative or recursive or both - is important, as is the OS-level security, controlling access, keeping up on patches, watching the logs. All of the usual security precautions apply to DNS as apply to *any* infrastructure subsystem.

As for Internet-facing DNS instances, even there, I think "hardware-level separation" between published-authoritative and recursive, is a little overblown. If you have a hardened platform, keep up on patches, have centralized configuration control, people who know what they're doing, multiple levels of redundancy for each function, ingress filtering, etc. then view-level separation is sufficient.

                                                                                        - Kevin

-----Original Message-----
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Gary Carr
Sent: Wednesday, August 05, 2015 10:19 AM
To: bind-users at lists.isc.org
Subject: separation of authoritative and recursive functions on internal networks

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!
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150805/ae52d001/attachment.html>