Over the years, we have had numerous discussions with our ISP partners about ways of integrating Whalebone's DNS resolvers into their infrastructure. One of the topics that is raised time and again is whether it would be possible to keep existing authoritative DNS servers and DNS resolvers on a single host. In the current post, we are going to delve into why this might not be the best approach and describe the reasons behind this architectural suggestion.
DISCLAIMER: The following examples are not meant to be exhaustive. There are configuration options available (e.g. ACLs, views, etc.) that can limit the attack surface and mitigate threats. However, this article refers to a commonly encountered setup where an authoritative DNS server is also acting as a resolver without any restrictions in place.Before proceeding to the main points, let’s briefly consider the unique characteristics and differences of the Authoritative DNS server nad Recursive Resolver:
Authoritative DNS Server:
- Reachable by anyone around the world
- Should answer only to non-recursive queries
- Should respond in an authoritative manner with data that they are responsible for
- Critical service for the DNS zones it maintains worldwide
Recursive Resolver (DNS Cache):
- Reachable only by local users
- Should respond to recursive queries
- Should be able to perform DNSSEC validation
- Critical service for all local users
As can be seen, there are fundamental differences that hint that their operations should be separated.
4 reasons to separate authoritative and recursive DNS servers
There are 4 main reasons why Recursive and Authoritative DNS servers should be kept separated. Now let’s explore these reasons in more detail:
Reason #1: Security
The security aspect of segregating DNS resolvers and authoritative servers is multi-tiered. Here is a sample categorization based on the impact of each threat:
a. Denial of Service Attacks / Availability
The critical nature of the DNS service calls for highly available deployments of authoritative and recursive servers.However, under the converged approach, a successful Denial of Service (DoS) attack to a by-design open to the world authoritative server will also impact the customer base using the same server for resolution.
Correspondingly, the opposite is also possible, a successful DoS (even unintentional) to a resolver takes down the authoritative server as well.
By segregating the two processes, the impact of such an attack is reduced and the potential damage is limited.
b. Impersonation Attacks / Integrity
Undoubtedly, domain name services are tied to the notion of trust that users have in a service. As a result, successful exploitation of an authoritative server could have detrimental effects. The attackers are able to take advantage of the affected domains and impersonate legitimate services. Moreover, in a case where the attackers have control over the zones, even protocols such as DNSSEC, which is ensuring the integrity of the domain names, can be trivially bypassed.
The situation could get even worse if the compromised shared host is also used by a resolver. Attackers are able to redirect not only the affected domain but other third-party services as well, such as search engines, banks, social networks. The damage could be disproportional and credential theft, fund exfiltration or sensitive user information exposure could occur.
c. Reflection Attacks / Availability - Liability
The most usual and well-known attack on unsecured resolvers is the "reflection" attack.
For this attack to work, a resolver serving requests to anyone (open resolver) is required. Malicious actors use these open resolvers in order to send a number of queries with a spoofed source IP address (that of the target of the attack). Consequently, the DNS servers respond to the spoofed address and eventually overwhelm it, rendering it unavailable.
The ease of execution, as well as the bandwidth multiplication factor (small request yields large response), make the attack extremely attractive to malicious parties.
In the case of unified authoritative and recursive DNS servers, protection from this kind of abuse is possible, but requires significantly complex steps, such as the definition of custom views and software-defined ACLs.
On the other hand, in case the two functions are separated, the recursive resolvers can be protected on an ACL level and be accessible only to local users, mitigating the threat.
d. Attacks on Privacy / Confidentiality
Lastly, when it comes to end-user’s privacy, a best practice for DNS resolvers is that they should not answer non-recursive queries. This is a measure against attacks that try to sneak into the contents of the DNS caches and retrieve the domains that have been accessed by end-users.
The principle behind this threat is that a domain that has been accessed by end-users will be present in the DNS cache for a short period of time (according to the TTL of the record). A malicious actor that can get responses to non-recursive queries is essentially able to "snoop" into the cache and its contents.
This is an imminent threat to users’ privacy and confidentiality, as attackers would be able to abuse the acquired information.
A use case which can be exploited is that of authoritative DNS servers. The operating principle is to answer these types of queries as they usually originate from recursive resolvers looking for authoritative answers. If the authoritative server is also a recursive resolver, user’s sensitive information can be exposed by enumerating the domains in the cache.
Reason #2: Performance
The performance of DNS servers has a direct impact on the end-user experience. Even a few milliseconds can make a huge difference on how the end-users browse, communicate and interact online.It is evident that infrastructure serving a large number of clients would have considerable resource requirements. The hosts can be provisioned by considering the expected load, but in case of some spike in traffic of either the authoritative or recursive services, both can be affected.A suitable solution to this is the “divide and conquer” strategy. By segregating the two functions, better utilization of the available resources can be achieved, resulting in enhanced performance, scalability and resilience.
Reason #3: Monitoring & Resilience
DNS servers, both authoritative and recursive, are getting increasingly complex and are undoubtedly part of the critical infrastructure that keeps the Internet running. It is important to ensure that the proper monitoring tools are in place and that any degradation of service can be easily investigated.Each type of DNS server has its own unique requirements and intricacies that need to be understood and configured.By keeping the two processes separated, gathering statistics can be forthright, and by keeping it in the unique context, actionable operational metrics can be exposed.Additionally, given that there are no overlapping components, troubleshooting is easier, and problems can be identified and solved.
Reason #4: Best practice
Lastly, it should be noted that the belief that authoritative and recursive servers should be run separated has been widely expressed in the past.Quoting from RFC2010:
"An organization's recursive DNS needs should be served by some other host than its root name server(s)."
Other DNS vendors such as BIND also include similar advice in their best practices both for recursive and authoritative server:
"Do not combine authoritative and recursive name server functions -- have each function performed by separate server sets [...] Ideally your Internet-facing authoritative servers should not perform recursion for any clients at all."
Result: Keep your recursive server separately... and try Whalebone
To sum up, the main 4 reasons why Recursive and Authoritative DNS servers should be kept separated are: Availability, Performance, Ease of Monitoring and Security. All 4 should be considered when making architectural choices and setting up a critical service such as DNS.With Whalebone, the deployment of a separate DNS resolver is now easier than ever! The resource requirements are minimal: 2 CPU cores, 4 GB of RAM, 40 GB HDD for serving up to 10,000 users and the installation can be as simple as copy-pasting a single one-line command at your own Linux VPS. See more details at Whalebone technical documentation.
