DNS is the backbone of network communications. Without DNS you would be forced to memorize the IP addresses of all the clients and servers on your network. That might have been something you could have done in 1985, but it’s really not realistic as we enter into the second decade of the 21st century. And DNS is going to be even more important as we slowly transition from IPv4 to IPv6. While some talented administrators could realistically remember the dotted quad addresses for dozens or maybe even hundreds of servers, that just isn’t going to happen with IPv6; where the IP addresses are 128bit hexadecimal numbers. IPv6 is going to bring DNS back to the forefront of your awareness.
Because DNS is going to be ever more important, you’re going to need to be sure that your DNS server solution is secure. Historically, there was a large amount of implicit trust in DNS deployments. There was an implicit trust that the DNS client could trust the DNS server, and there was implicit trust that the records returned from the DNS server to the DNS client were valid. While this “gentleman’s agreement” has worked reasonably well for the last few decades, the time has come when we need to be able to guarantee that the information provided by the DNS server is valid and that client/server DNS communications are secure.
This has me thinking about the Windows Server 2008 R2 DNS server. There are several new features in the Windows Server 2008 R2 DNS server that you can use to improve the overall security of your DNS infrastructure. These include:
- DNS Security Extensions (DNSSEC)
- Control over DNS devolution behavior
- DNS cache locking
- DNS Socket Pool
In this article, I’m going to provide you a brief overview of each of these features and how you can use them to create a more secure DNS for your network.
DNS Security Extensions (DNSSEC)
DNSSEC is a group of specifications from the Internet Engineering Task Force (IETF) that provide for origin authentication of DNS data, authenticated denial of existence and data integrity (not data confidentiality). The purpose of DNSSEC is to protect against forged DNS information (for example, DNS cache poisoning), by using digital signatures.DNSSEC is actually a collection of new features added to the DNS client/server interaction that help increase the security of the basic DNS protocols. The core DNSSEC features are specified in:
- RFC 4033
- RFC 4034
- RFC 4035
DNSSEC introduces several new terms and technologies on both the client and server side. For example, DNSSEC adds four new DNS resource records:
Windows Server 2008 R2 Implementation
Windows Server 2008 R2 and Windows 7 are the first Microsoft operating systems to support DNSSEC. You can now sign and host DNSSEC signed zones to increase the level of security for your DNS infrastructure. The following DNSSEC related features are introduced in Windows Server 2008 R2:
- The ability to sign a zone (that is, to provide the zone a digital signature)
- The ability to host signed zones
- New support for the DNSSEC protocol
- New support for DNSKEY, RRSIG, NSEC, and DS resource records.
DNSSEC can add origin authority (confirmation and validation of the original of the DNS information presented to the DNS client), data integrity (provide assurance that the data has not been changed), and authenticated denial of existence to DNS (a signed response confirming that the record does not exist).
Windows 7/Server 2008 R2 DNS Client Improvements
In addition to the DNS server updates in Windows Server 2008 R2, there are some improvements in the Windows 7 DNS client (which also includes the DNS client service in Windows Server 2008 R2):
- The ability to communicate awareness of DNSSEC in DNS queries (which is required if you decide to used signed zones)
- The ability to process the DNSKEY, RRSIG, NSEC, and DS resource records.
- The ability to determine if the DNS server with to which it had sent a DNS query has performed validation for the client.
DNSSEC and the NRPT
If you’re acquainted with DirectAccess, you might be interested in the fact that DNSSEC leverages the Name Resolution Policy Table (NRPT). The DNS client DNSSEC related behavior is set by the NRPT. The NRPT enables you to create a type of policy based routing for DNS queries. For example, you can configure the NRPT to send queries for contoso.com to DNS server 1, while queries for all other domains are sent to the DNS server address configured on the DNS client’s network interface card. You configure the NRPT in Group Policy. The NRPT is also used to enable DNSSEC for defined namespaces, as seen in Figure 1 below.
Understanding how DNSSEC works
A key feature of DNSSEC is that it enables you to sign a DNS zone – which means that all the records for that zone are also signed.The DNS client can take advantage of the digital signature added to the resource records to confirm that they are valid. This is typical of what you see in other areas where you have deployed services that depend on PKI. The DNS client can validate that the response hasn’t been changed using the public/private key pair. In order to do this, the DNS client has to be configured to trust the signer of the signed zone.
The new Windows Server 2008 R2 DNSSEC support enables you to sign file-based and Active Directory integrated zones through an offline zone signing tool. I know it would have been easier to have a GUI interface for this, but I guess Microsoft ran out of time or figured that not enough people would actually use this feature to make it worthwhile to make the effort to create a convenient graphical interface for signing a zone. The signing process is also done off-line. After the zone is signed, it can be hosted by other DNS servers using typical zone transfer methodologies.
When configured with a trust anchor, a DNS server is able to validate DNSSEC responses received on behalf of the client. However, in order to prove that a DNS answer is correct, you need to know at least one key or DS record that is correct from sources other than the DNS. These starting points are called trust anchors.
Another change in the Windows 7 and Windows Server 2008 R2 DNS client is that it acts as a security-aware stub resolver. This means that the DNS client will let the DNS server handle the security validation tasks, but it will consume the results of the security validation efforts performed by the DNS server. The DNS clients take advantage of the NRPT to determine when they should check for validation results. After the client confirms that the response is valid, it will return the results of the DNS query to the application that triggered the initial DNS query.
Using IPsec with DNSSEC
In general, it’s a good idea to use IPsec to secure communications between all machines that participate on your managed network. The reason for this is that it’s very easy for an intruder to put network analysis software on your network and intercept and read any non-encrypted content that moves over the wire. However, if you use DNSSEC, you’ll need to be aware of the following when crafting your IPsec policies:
- DNSSEC uses SSL to secure the connection between the DNS client and server. There are two advantages of using SSL: first, it encrypts the DNS query traffic between the DNS client and DNS server, and second, it allows the DNS client to authenticate the identity of the DNS server, which helps ensure that the DNS server is a trusted machine and not a rogue.
- You need to exempt both TCP port 53 and UDP port 53 from your domain IPsec policy. The reason for this is that the domain IPsec policy will be used and DNSSEC certificate-based authentication will not be performed. The end result is that the client will fail the EKU validation and end up not trusting the DNS server.
Control Over DNS Devolution
DNS devolution has been available for a long time in Windows DNS clients. No, it doesn’t mean that the operating systems are less evolved. Devolution allows your client computers that are members of a subdomain to access resources in the parent domain without the need to provide the exact FQDN for the resource.
For example, if the client uses the primary DNS suffix corp.contoso.com and devolution is enabled with a devolution level of two, an application attempting to query the host name server1 will attempt to resolve:
- server1.corp.contoso.com and
Notice that when the devolution level is set to two, the devolution process stops when there are two labels for the domain name (in this case, corp.com).
Now, if the devolution level were set to three, the devolution process would stop with server1.corp.contoso.com, since server1.contoso.com only has two labels in the domain name (contoso.com).
However, devolution is not enabled in Active Directory domains when:
- There is a global suffix search list assigned by Group Policy.
- The DNS client does not have the Append parent suffixes of the primary DNS suffix check box selected on the DNS tab in the Advanced TCP/IP Settings for IPv4 or IPv6 Internet Protocol (TCP/IP) Properties of a client computer’s network connection, as shown in Figure 2. Parent suffixes are obtained by devolution.
Previous versions of Windows had an effective devolution level of two. What’s new in Windows Server 2008 R2 is that you can now define your own devolution level, which gives you more control over the organizational boundaries in an Active Directory domain when clients try to resolve names in the domain. You can set the devolution level using Group Policy, as seen in Figure 3 below (Computer Configuration\Policies\Administrative Templates\Network\DNS Client).
DNS Cache Locking
Cache locking in Windows Server 2008 R2 enables you to control the ability to overwrite information contained in the DNS cache. When DNS cache locking is turned on, the DNS server will not allow cached records to be overwritten for the duration of the time to live (TTL) value. This helps protect your DNS server from cache poisoning. You can also customize the settings used for cache locking.
When a DNS server configured to perform recursion receives a DNS request, it caches the results of the DNS query before returning the information to the machine that sent the request. Like all caching solutions, the goal is to enable the DNS server to provide information from the cache with subsequent requests, so that it won’t have to take the time to repeat the query. The DNS server keeps the information in the DNS server cache for a period of time defined by the TTL on the resource record. However, it is possible for information in the cache to be overwritten if new information about that resource record is received by the DNS server. One scenario where this might happen is when an attacker attempts to poison your DNS cache. If the attacker is successful, the poisoned cache might return false information to DNS clients and send the clients to servers owned by the attacker.
Cache locking is configured as a percentage of the TTL. For example, if the cache locking value is set to 25, then the DNS server will not overwrite a cached entry until 25% of the time defined by the TTL for the resource record has passed. The default value is 100, which means that the entire TTL must pass before the cached record can be updated. The cache locking value is stored in theCacheLockingPercent registry key. If the registry key is not present, then the DNS server will use the default cache locking value of 100. The preferred method of configuring the cache locking value is through the dnscmd command line tool.
An example of how to configure cache locking is seen in Figure 4 below. The percent value can range from 0 to 100.
Swimming in the Windows Server 2008 R2 DNS Socket Pool
OK, so you can’t swim in a socket pool. But what you can do with the Windows Server 2008 R2 DNS socket pool is enable the DNS server to use source port randomization when issuing DNS queries. Why would you want to do this? Because the source port randomization provides protection against some types of cache poisoning attacks, such as those described over here.
The initial fix included some default settings, but with Windows Server 2008 R2 you can customize socket pool settings.
Source port randomization protects against DNS cache poisoning attacks. With source port randomization, the DNS server will randomly pick a source port from a pool of available sockets that it opens when the service starts. This helps prevent an unauthenticated remote attacker from sending specially crafted responses to DNS requests in order to poison the DNS cache and forward traffic to locations that are under the control of an attacker.
Previous versions of the Windows DNS server used a predictable collection of source ports when issuing DNS query requests. With the new DNS socket pool, the DNS server will use a random port number selected from the socket pool. This makes it much more difficult for an attacker to guess the source port of a DNS query. To further thwart the attacker, a random transaction ID is added to the mix, making it even more difficult to execute the cache poisoning attack.
The socket pool starts with a default of 2500 sockets. However, if you want to make things even tougher for attackers, you can increase it up to a value of 10,000. The more sockets you have available in the pool, the harder it’s going to be to guess which socket is going to be used, thus frustrating the cache poisoning attacker. On the other hand, you can configure the pool value to be zero. In that case, you’ll end up with a single socket value that will be used for DNS queries, something you really don’t want to do. You can even configure certain ports to be excluded from the pool.
Like the DNS cache feature, you configure the socket pool using the dnscmd tool. The figure below shows you an example using the default values.
In this article we went over several new features included in the Windows Server 2008 R2 server and Windows 7 DNS client that increase the security and performance of your DNS infrastructure. The combination of DNSSEC, improvements in control over DNS devolution, security enhancements in the DNS cache and the DNS socket pool all provide compelling reasons to upgrade your DNS servers to Windows Server 2008 R2.