DNS Deployment – Split Split Environment

I recently provided a security review for a customer that revolved around their current deployment of BIND with a clustered DNS deployment and how I would recommend securing it to a higher degree. My recommendations focused around the implementation of a split-split DNS design.

This would create a multi level deployment between the Internal Network, DMZ and the outside world. This configuration is designed around a high availability, fault tolerant design, with the major drawback being that large amount of hardware required to implement it. This configuration necessitates the use of:

  • Two Resolver DNS servers in a DMZ
  • Two Advertiser DNS servers in a DMZ
  • Two DNS servers internal on the local area network

There are two servers of each type to allow the fault tolerance and the load balancing. For each type of server DNS, there will be a primary and a secondary. There is zone transfers only between the primary and secondary servers.

Split Split DNS

Figure 1: Split-Split DNS

An authoritative DNS is a DNS server containing zones of which it has the authority. For example, if you had the authority on loc1.customer.com and loc1.subsidiary.com you would put zones for each one of these fields on authoritative server DNS. The authoritative DNS must be protected from pollution of his cache and does not use recursion.

Configuring an authoritative DNS varies from operating system to operating systems, but certain key items must always happen:

  1. The disabling of recursion must take place
  2. The cache must be protected against poisoning

You do not want the authoritative (advertiser) server carrying out recursive requests. The authoritative server provides information for the zones under your authority. If a client tries to question a name whose server does not have authority, the server returns a message “server failure”. You prevent the majority and the most dangerous exploits of DNS by disabling recursion.

The DNS Resolvers in the DMZ are DNS servers in cache mode which act as forwarders for the servers of DNS on the internal network. These DNS servers in cache mode do not have any zone installed. They are only used to solve and put in cache the requests which they solved for the servers of DNS on the internal network. Since these machines are not authoritative on any field, there is no risk which your fields are prone to attacks DNS on these servers.

The internal servers of DNS solve queries for the internal clients on the network. You point out that the path used by the clients of the internal network to reach resources on the internal network has to be different from the paths used by the external clients. The difference lies in the contents of the zones installed on the internal DNS server and authoritative DNS server.

This will allow internal network client to make a query for a DMZ resource in the following way:

  1. The internal network client is configured to send DNS queries to the internal network DNS server. The client sends a request for www.customer.com
  2. The DNS server responds to the request with the IP address of www.customer.com, which is the actual IP address of the server on the private address DMZ – 10.0.0.1

This will allow external systems to make a query for a DMZ resource in the following way:

  1. The external network client queries an Advertising DNS server on the DMZ for www.customer.com.
  2. The DNS Advertiser on the DMZ sends the IP address on the external interface that is being used to publish the Web server on the DMZ.

Once again you see that the external network client uses a different path to access the same resource on the DMZ segment.

With larger networks, like the customer I was working for, you should consider putting together a “split-split” DNS setup. The is the best arrangement for allowing efficient name resolution for internal and external network clients while at the same time protecting your public DNS servers from being compromised by cache pollution and DNS hijacking exploits.

Posted in DNS, General. Tags: , , .

Leave a Reply