"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: [email protected]
[mailto:[email protected]] On Behalf Of Gary Carr
Sent: Wednesday, August 05, 2015 10:19 AM
To: [email protected]
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
[email protected]<mailto:[email protected]>
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
