12.1 Setting up the Recursive Service
As discussed earlier in this document, the DNS consists of two basic components: Authoritative name servers that publish DNS data, and DNS resolvers that issue queries for DNS data. Resolvers can be further broken down into two general categories: Stub resolvers (often found on individual hosts) that issue queries, but cannot follow DNS referrals, and recursive resolvers/servers that can follow referrals.
The typical set up within an enterprise is to have one or two recursive resolvers/servers providing DNS resolution for all the stub resolvers on the network.
The security threats to an enterprise’s recursive resolver/server infrastructure differ slightly from the security threats to its authoritative name servers. Likewise, the measures taken to secure a recursive server differ from an authoritative name server.
12.1.1 Threats to Recursive Servers/Resolvers
Recursive and stub resolvers share a set of threats with authoritative name servers. These threats include the general threats to the host platform (see Section 5.1) and threats to software used to perform DNS transactions (see Section 5.2). However, since recursive (and stub) resolvers do not have zone files (except the root hints file used by recursive resolvers) the administrator only needs to focus on configuration files. The differences would be:
The threats to DNS data contents (Section 5.3) do not directly apply to recursive and stub resolvers as they do not have control over the DNS information published; they only consume it.
12.1.2 Securing the Host Platform for Recursive Servers/Resolvers
Section 7 gives the basic steps in securing the host platform of any DNS component such as running the latest version of software, isolating it on a dedicated server, being aware of known vulnerabilities.
Administrators should refer to the relevant Checklist Items from Section 7 with the knowledge that recursive servers do not have zone files (except the root hints file) so there is no need to partition the file as described in Section 7.2.8.
There are additional steps an administrator can take when setting up a recursive server for an enterprise.
Since it is unwise to allow queries from the outside Internet to the recursive server, the recursive server can be placed behind a firewall that blocks inbound connections from UDP and TCP port 53 (used by DNS).
Recursive servers should be configured to only accept queries from internal hosts. This is done using the allow-query sub-statement as described in Section 8.1.1.
Checklist item 37: Recursive servers/resolvers should be placed behind an organization’s firewall and configured to only accept queries from internal hosts (e.g., Stub Resolver host).
Stub resolvers do not have many configuration options. Often the only configuration necessary for an administrator is to enter the IP addresses of one or more recursive resolvers that the stub would rely on to service queries. It is a good idea for administrators to include at least two IP addresses of recursive
servers to increase the availability of the DNS service for end users. This can be done manually, or using a protocol like DHCP.
There is a known class of malware that attempts to change the settings on a system’s stub resolver to direct queries to another (usually malicious) recursive server. The server may then direct end users to a malicious site where another attack takes place, or the server may simply direct users to a webpage that serves ads or similar non-intended content. To combat this, administrators should make sure end user systems have the latest anti-virus/malware software and should consider blocking all outbound DNS traffic with the exception of known recursive servers.
Checklist item 38: Administrators should configure two or more recursive resolvers for each stub client on the network.
Checklist item 39: Enterprise firewalls should consider restricting outbound DNS traffic to only the enterprise’s designated recursive resolvers.
12.2 Guidelines for Establishing Servers
Enterprise network administrators should set up their recursive server infrastructure with availability and speed of service in mind. However, security is a concern as well as enterprises realize the vulnerability of the DNS to spoofing and importance of monitoring DNS traffic.
12.2.1 Aggregate Caches
Larger enterprises that want to minimize their external network presence may want to consider deploying aggregate caches. An aggregate cache is a recursive resolve that exists on an enterprises’ DMZ and only accepts forwarded queries from other recursive resolvers (sometimes called forwarders in this scenario).
This reduces the number of servers that need monitoring on the DMZ, but still allows for local recursive servers for separate network segments in an enterprise.
The figure below shows how multiple forwarders send queries to the aggregate cache, which then performs any recursion necessary to find the final answers. The individual forwarders may have their own cache, as well as act as secondaries for internal zones. This is to provide faster service for local stub resolvers.
SECURE DOMAIN NAME SYSTEM (DNS)DEPLOYMENT GUIDE
12-16
Figure 12-1: Example of Resolver Architecture Using an Aggregate Cache.
When the local forwarder receives a query it cannot answer out of cache (or authoritative data, if present) it forwards the query on to the aggregate cache for recursion. The aggregate cache then performs the recursion and returns the final answer to the forwarder, which in turn sends the final answer back to the stub resolver.
DNSSEC validation on an enterprise with aggregate caches is slightly more complicated than an enterprise that does not use aggregate caches. It is considered wise to perform validation as close to the stub resolver as possible, which in this scenario would mean the forwarder. However, if the aggregate cache does not perform validation, there is the risk of the aggregate cache having DNSSEC invalid data in its cache that would then be sent back to the forwarders. This BOGUS data would only be purged upon the TTL expiration, and not be updated with valid data until that time as passed.
One solution is to perform validation at the forwarder and the aggregate cache, and have the forwarder send all queries to the aggregate cache with the Checking Disable (CD) bit flag set. That signals to the aggregate cache that the forwarder wishes to perform its own validation and should receive the full response back. The aggregate cache is still free to perform its own validation of the data, and the resulting caches on both sides will remain in sync.
Checklist item 40: Whenever Aggregate Caches are deployed, the forwarders must be configured to be Validating Resolvers.
Stub resolvers do not have many configuration options. Often the only configuration necessary for an administrator is to enter the IP addresses of one or more recursive resolvers that the stub would rely on to service queries. It is a good idea for administrators to include at least two IP addresses of recursive servers to increase the availability of the DNS service for end users. This can be done manually, or using a protocol like DHCP.
There is a known class of malware that attempts to change the settings on a system’s stub resolver to direct queries to another (usually malicious) recursive server. The server may then direct end users to a malicious site where another attack takes place, or the server may simply direct users to a webpage that serves ads or similar non-intended content. To combat this, administrators should make sure end user systems have the latest anti-virus/malware software and should consider blocking all outbound DNS traffic with the exception of known recursive servers.
Checklist item 41: Administrators should configure two or more recursive resolvers for each stub client on the network.
Checklist item 42: Enterprise firewalls should consider restricting outbound DNS traffic to only the enterprise’s designated recursive resolvers.
12.3 Setting up the Root Hints File
Every recursive server needs to know the IP address of one or more root servers. If the recursive server cannot find the answer to a stub resolver’s query in its cache, it must perform a recursive lookup for the correct information to respond to the client. It does this by first sending the query to one of the root zone servers and following one or more referrals until it reaches one of the authoritative servers of the DNS zone data. See Section 2.2 for a more detailed discussion of the DNS resolution process.
The IP addresses of the root servers are stored in a file often referred to as the root hints file. It is not considered authoritative information, but only hints for the locations of the root zone servers. On startup (and regular intervals), recursive servers send queries to each IP address in the root hints file for the full list of root zone servers. It then maintains this information in its cache until it is time to refresh this data.
It is also necessary for a human administrator to also regularly check the contents of the root hints file for any necessary updates. Missing any changes to the set of root zone servers may result in delays at startup (while waiting for queries to time out) or security vulnerabilities (attackers using spoofed root zone IP addresses). The list of public DNS root zone servers are maintained as part of the IANA functions13 and administrators can download the current root hints file as well as the DNSSEC public key of the root zone.
13 http://www.iana.org/domains/root/files
SECURE DOMAIN NAME SYSTEM (DNS)DEPLOYMENT GUIDE
12-18
Checklist item 43 : Each recursive server must have a root hints file containing the IP address of one or more DNS root servers. The information in the root hints file should be periodically checked for correctness.
Checklist item 44 : The root hints file should be owned by the account under which the name server software is run. The permission bits should be set so that the root hints file can be read or modified only by the account that runs the name server software.
12.4 Securing the Stub Resolver
Stub resolvers do not have many configuration options. Often the only configuration necessary for an administrator is to enter the IP addresses of one or more recursive resolvers that the stub would rely on to service queries. It is a good idea for administrators to include at least two IP addresses of recursive servers to increase the availability of the DNS service for end users. This can be done manually, or using a protocol like DHCP.
There is a known class of malware that attempts to change the settings on a system’s stub resolver to direct queries to another (usually malicious) recursive server. The server may then directs end users to a malicious site where another attack takes place, or the server may simply direct users to a webpage that serves ads or similar non-intended content. To combat this, administrators should make sure end user systems have the latest anti-virus/malware software and should consider blocking all outbound DNS traffic with the exception of known recursive servers.
Checklist item 45: Administrators should configure two or more recursive resolvers for each stub resolver on the network.
Checklist item 46: Enterprise firewalls should consider restricting outbound DNS traffic from stub resolvers to only the enterprise’s designated recursive resolvers.
12.5 Recommendations Summary
• Checklist item 37: Recursive servers/resolvers should be placed behind an organization’s firewall and configured to only accept queries from internal hosts (e.g., Stub Resolver host).
Checklist Item 38: Whenever Aggregate Caches are deployed, the forwarders must be configured to be Validating Resolvers.
• Checklist item 39 : Each recursive server must have a root hints file containing the IP address of one or more DNS root servers. The information in the root hints file should be periodically checked for correctness.
• Checklist item 40 : The root hints file should be owned by the account under which the name server software is run. The permission bits should be set so that the root hints file can be read or modified only by the account that runs the name server software.
• Checklist item 41: Administrators should configure two or more recursive resolvers for each stub resolver on the network.
• Checklist item 42: Enterprise firewalls should consider restricting outbound DNS traffic from stub resolvers to only the enterprise’s designated recursive resolvers.
• Checklist item 43 : Each recursive server must have a root hints file containing the IP address of one or more DNS root servers. The information in the root hints file should be periodically checked for correctness.
• Checklist item 44 : The root hints file should be owned by the account under which the name server software is run. The permission bits should be set so that the root hints file can be read or modified only by the account that runs the name server software.
• Checklist item 45: Administrators should configure two or more recursive resolvers for each stub resolver on the network.
• Checklist item 46: Enterprise firewalls should consider restricting outbound DNS traffic from stub resolvers to only the enterprise’s designated recursive resolvers.
SECURE DOMAIN NAME SYSTEM (DNS)DEPLOYMENT GUIDE
13-20