5.2 Domain Name System Servers


5.2 Domain Name System Servers

To a computer, an IP address is simply a string of 32 ones and zeros. We humans, however, have a difficult time remembering when someone tells us to PING the IP address 11000000101101000000000000000001. Instead, to keep our sanity, we represent this string of ones and zeros in 8-bit chunks and then translate each of those 8-bit chunks into decimal numbers, with which we are more familiar. It is much easier to PING 192.168.0.1.

Even this abstraction is not workable in the long run, however. It simply would not do to remember that Proteris had servers in the IP address range of 200.0.0.5–30, except for the mail server, which was hosted at another location and had its IP address of 134.0.100.10. In an effort to further simplify the usability of network resources, it did not take network engineers long to create something known as an alias. In its purest form, an alias is simply a text string that is associated with an IP address. For example, I used a text file on my home office network called hosts.txt. Each machine had an identical copy of this file and it was used to provide a mnemonic shortcut to IP addresses. This text file has a number of entries in it that look like:

     192.168.10.10     Calvin     192.168.10.11     Hobbes     192.168.10.12     Bart     192.168.10.13     Lisa, etc. 

When testing network configurations and rapidly moving from host to host over the network, I do not need to trouble myself with the IP addresses of each host. I simply type "SSH Calvin" or "SSH Bart." The source host examines the host.txt file and automatically translates my query into an IP address. While this is a very simple system, each time I added a new machine to the network, this file would have to be updated on all other hosts to ensure that the host.txt file remained consistent. As the network grew to over 20 devices, this system became unwieldy. Instead, it was simpler to maintain a single database at a central location and configure all devices to query that single device for a name to address resolution. The server that I installed to serve as the central database was, of course, a DNS server.

Much of the early Internet used a system very similar to this for access to networked hosts. Host files were stored locally to each networked device and updated on a regular basis. As the number of networked devices grew, network engineers discovered long ago the same thing I discovered in my own office — keeping multiple database files up-to-date was an unmanageable task. The issue was further complicated by the fact that multiple government and educational facilities were trying to manage their own domains. Because the entire host file was essentially a flat database, a change to one network meant that all other network administrators had to update their own host files.

The domain name system was developed in an effort to decentralize the management of name to address translation tables. Ideally, nobody really would need to know that State U had changed the IP address of the Web server www.stateu.edu from 145.15.9.10 to 145.15.9.11, especially if others never had the need or desire to connect to the Web server.

The DNS is what is known as a distributed hierarchical database. Starting from a central point, the "root," the domain space is broken into several top-level domains. Each of these top-level domains is, in turn, broken into domains, which are in turn broken into sub-domains or hosts. In the example shown in Exhibit 1, we see a logical representation of this structure. As an example, there is a "Proteris" domain as part of the .com and .net top-level domains. Each Proteris domain, in turn, may be further subdivided into sub-domains or include hosts in the Proteris domain itself. We see in Exhibit 1 that each Proteris domain contains a Web server with the host name "www." To unambiguously differentiate between the two occurrences of Proteris Web server, DNS names are always referred to using the full domain structure, as in www.proteris.com and www.proteris.org. This format of identifying hosts through the use of sub-domains (if present), domains, and top-level domains is known as a fully qualified domain name (FQDN).

Exhibit 1: The Logical Structure of the DNS Name Space

start example

click to expand

end example

A DNS server is an application service that runs on a host. The DNS process refers to a number of text files. There are a number of files that allow a DNS server to provide full functionality, but the two most important ones are the zone file and the in.addr file. The zone file contains host names such as www, mail, server_1, etc. Each host in the zone file is associated with an IP address. Each time a request for a host that is part of a domain (such as proteris.com) is sent to the DNS server, this file is consulted to find the requested host name and return the appropriate IP address in response to the query. The in.addr file performs just the opposite function. It contains IP addresses and the associated host name. When a request is sent to the DNS server to ensure that a particular IP address is really part of a given domain, this file is checked. The structure of these files can be seen in Exhibit 2.

Exhibit 2: Sample DNS .zone and in.addr Files

start example

click to expand

end example

At the top of the DNS hierarchy is a set of servers known as root servers. These are the servers that contain information on how to get to all other DNS servers in the world. The root DNS servers then have no information about host names or sub-domains. They simply know where to find the authoritative server for each domain. If, for example, you want to browse to www.proteris.com, your Web browser would make a request for a name to address resolution to your local DNS server. Assuming your local DNS server did not have such a mapping in place, it would then make a request to a root server that could be paraphrased as, "Do you know where the DNS server that has information about the proteris.com domain can be found?" The root would respond back with the IP address of the proteris.com DNS server. Your DNS server would then send a request to the proteris.com DNS server that could be paraphrased as, "I'm looking for the host named www. Do you have any host that matches that name in your zone file?" The zone file would be referenced and the proper IP address would be returned to your DNS server to be forwarded to your host to complete the browsing process.

There are currently 13 root servers in the world today. Some of these 13 root servers are not single servers, but actually clusters of servers. They are built to handle a fantastic number of requests per second and are located at some of the major hubs of the Internet. Even this hardware, however, cannot always keep up with demand. In an effort to make the DNS resolution process described in the preceding paragraph more efficient, DNS servers often cache name-to-address mappings in case anyone else wishes to make a similar request. Thus, if one of your co-workers wished to visit www.proteris.com, your local DNS server would already have the IP address cached from your earlier request. Many times, an upstream cache is utilized as well. This means that if your local DNS server did not have an available translation for your initial request, then instead of immediately forwarding a request to the root server, it may query another DNS server, typically one maintained by your service provider. The logic of this is that because the service provider theoretically answers requests for a larger number of hosts than your company, odds are that someone from another location has already made a request for the same name-to-address resolution you are making.

5.2.1 DNS Security Concerns

The primary role of DNS is simply the name-to-address translation and address-to-name translation that it provides. This simple role, however, has major security implications. From what we now know of the DNS process, we can easily identify some points of concern.

The first is simply the entering of incorrect information into the system. Using the example of my test network, if someone were able to hack into the network and change the address resolution of the host Calvin, I could go on using the alias Calvin without knowing that I was actually being diverted to another host. Apply this on a larger scale and we have problems. If, for example, you were diverted to another Web site that looked exactly like the first one (a trivial process), you may be tempted to try to log in using a username and password. You may even be tempted to shop for a product and enter credit card information. DNS has been the victim of some spectacular vulnerabilities that have made these types of attacks possible. While patches are released to patch the latest vulnerability, odds are that there are going to be new ones in the future.

The zone file that is part of every DNS implementation is also an attractive target for someone simply seeking to learn information about a target company. To ensure availability of the DNS, DNS servers have a built-in ability to transfer the entire zone file to another host. Many times, however, this transfer is not restricted to only a designated backup host. Instead, anyone making a request for the zone transfer can receive it. This file, having a mapping of all host names, aliases, and the IP address of hosts on the network is a fantastic resource for anyone seeking information for a later attack on the network.

Cached DNS entries are also vulnerable to attack. Many DNS servers will simply cache a name to address resolution packet when they receive it — even if they had never made a request for that name in the first place. This means that an attacker can send a crafted DNS query response to a caching DNS server and point a popular network resource to an alternate host. Anyone downstream of the cache will then be redirected to the cached, illegitimate address instead of the legitimate destination. This process, known as cache poisoning, allows an attacker to give the appearance of your site having been hacked without ever having to have actually compromised your network.

Finally, although DNS is not required for Internet connectivity in a strictly technical sense, it is essential for humans to be able to make productive use of network resources. Being able to take a DNS server offline is normally just as effective as launching a denial-of-service attack on a site, as is flooding the targets access-link with traffic. If the normal end user cannot receive proper name resolution for the destination, it is unlikely that they will ever be able to visit your site.

Due to the critical nature of DNS and the multiple avenues that can be used to compromise either a DNS server or the service they provide, special care must be taken when considering the implementation of a DNS server. One common solution attempting to reduce this risk is the implementation of a split DNS configuration. Split DNS, as the name suggests, is the configuration of multiple DNS servers to serve a network. One DNS server is placed on the internal network or as part of the local LAN server farm and the second DNS server is placed in the DMZ as illustrated in Exhibit 3. The internal DNS server operates as a normal DNS server and LAN hosts are configured to query this DNS server for name-to-address resolutions. The zone files on the LAN are complete and have name-to-address information for all hosts. The DMZ DNS server, on the other hand, has only zone information for hosts that would normally be accessible to the public. Even if the DMZ DNS server were compromised, the attacker has discovered no information that could not already be easily found.

Exhibit 3: Split DNS Example

start example

click to expand

end example

It is important to configure two DNS servers. I have found that some network administrators attempt to outsmart themselves by setting up either two separate zone files on a single DNS server or running two DNS processes on a single server. Separation in this case can be achieved by installing two network interface cards on a single device. While this may make financial and logical sense, it suffers from two critical flaws. The first is that the entire point of a DMZ is the assumption that despite your best efforts, hosts in the DMZ will be compromised. Once this has been accomplished, you cannot guarantee the integrity of either your internal or external DNS databases. The second problem is that once this host is compromised, due to the multiple network interface cards, you have created a backdoor past your firewall into your internal network. It seems silly, but I have seen this configuration in practice. Do not do it.




Network Perimeter Security. Building Defense In-Depth
Network Perimeter Security: Building Defense In-Depth
ISBN: 0849316286
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Cliff Riggs

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net