Domain Name System
By: Teresa M. Wade

In today’s society, technology has made life very convenient. One of those conveniences is the World Wide Web (WWW) commonly known as the Internet. From the touch of a button or a click of a mouse a user can gain access to a plethora of information. There are many different protocols and services that are interconnected to provide this ability. One such service is called Domain Naming System (DNS). DNS is an Internet service that translates domain names into IP addresses. This may not seem like a big deal to most but many would beg to differ if they had known that without DNS they would have to remember billions of numbers. Everything in a network has an IP address. DNS helps us designate what those devices are. There are 3 basic components of DNS which are zones (or namespace), name servers and resolvers. In the following reading you will learn what DNS is as well as the working components that make it as reliable as it is today. DNS was invented in 1983 shortly after Transmission Control Protocol/Internet Protocol (TCP/IP) was deployed. DNS operates on port 53 and utilizes User Datagram Protocol (UDP). The only time that the Transmission Control Protocol is used is when the response size exceeds 512 bytes. The only time that UDP can be used to transport more than 512 bytes is if EDNS is used. EDNS is basically an extension of DNS. Before the use of DNS, every computer on the network would retrieve a file called HOST.txt from a computer at SRI International. SRI is a contract research institute that focuses on communications, networks, robotics, and other forms of Information Technology (IT). This file would map numerical addresses to websites such as 131.22.25.212 to a website named www.teresa.com. Though this file was helpful the biggest limitation was that every time a given computer's address changed, every computer that seeks to communicate with it would need to update its hosts file. The growth of networking required a more scalable system that recorded a change in a host's address in one location only. Other hosts would learn about the change dynamically through a notification system, thus completing a globally accessible network of all hosts' names and their associated IP addresses. So before we talk about this dynamic notification let’s look at the basics of a domain. The domain name system uses a tree name structure. At the top of the tree is the root and followed by the top level domains and a number of lower levels. A domain name is separated by a period. The label on the right side is the top level domain (.com) and the left side is a sub-domain (yahoo). The terms domain and sub-domain are interchangeable. Sub-domain is typically a term relative to domain and refers to a domain contained within full domain. When a node is added to the left hand side you get a Fully Qualified Domain Name (FQDN). DNS is separated into zones and each zone is served by a name server, which can host several zones. A zone is a collection of connected nodes. A name server that has complete information for that zone is said to be an authority for that zone. When an IP address or hostname is resolved it searched through several name servers. If a name server is not working then a host cannot access any resource on the network. That is the reason for several name servers. If the primary does not respond then a host can use the secondary. Name servers are listed by name rather than by IP address. The difference between a domain and zone is subtle. A zone contains the domain names and data that a domain contains *except* for the domain names and data that are delegated elsewhere. Using the term delegated means making someone else responsible for the sub domain. This delegation property is why DNS is often called a distributed database. (DNS and BIND, 2000) The basic unit of data in DNS is called a resource record. Each record has a designated type such as A or MX (WindowsITPro, 2001). An A type is the most common. It translates a domain name into an IP address. A CNAME uses an alias for an internet address. A Pointer Record, or PTR, is used for reverse queries. That is if you have the IP address but not the hostname. That's why PTR records have become important. Originally, PTR records were just intended as a convenience. There still are no requirements that you have a PTR record but because of the abuse of the internet by spammers it is sometimes necessary. An MX record or Mail Exchanger record specifies how Internet e-mail should be routed using the Simple Mail Transfer Protocol (SMTP). Each MX record contains a preference and a host name, so that the collection of MX records for a given domain name point to the servers that should receive e-mail for that domain, and their priority relative to each other (MX Record, 2009). An NS record will list which name servers can answer the DNS requests. Records that have the same type are known as a set. There are 6 different sections to a resource record: NAME, TYPE, RDATA, TTL, RDLENGTH, and CLASS. The NAME is fully qualified domain name. The TYPE, as mentioned above, is the format of the data. RDATA depends on what the TYPE of the record is. RDATA is the data portion of the resource record. It can either be a mail host for MX records or an IP address for A records. CLASS specifies the class of the resource record being requested, normally the value 1 for Internet (TCP/IP Guide, 2005). RDLENGTH indicates the size of the RDATA field, in bytes and the TTL Specifies the number of seconds that the record should be retained in the cache of the device reading the record. A value of zero means “use this information for the current name resolution only; do not cache it”. Now let’s talk about caching on DNS servers. To begin the DNS resolution local machines contact a root server, the top node is called the root domain, who in turn contacts the next domain and so forth until it resolves the address. A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries. A non-recursive query is one in which the DNS server may provide a partial answer to the query (or give an error). This can sometimes be too much for the root server since at any given time there are billions of queries kicking off. To keep the server for crashing, caching is used to reduce the load on individual servers. Caching is used by DNS name servers to store the results of recent name resolution and other requests, so that if the request occurs again it can be satisfied from the cache without requiring another complete run of the name resolution process. Due to how most people use computers, a particular request is often followed by another request for the same name, so caching can significantly reduce the number of requests that result in complete name resolution procedures. Caching allows successful resolution responses to remain valid on the server for a predetermined amount of time. This time is called Time To Live (TTL) and is set by the Administrator of the DNS server and can vary from seconds to weeks. If the resolution is not successful then nothing will be saved. In the beginning of my career I have heard many co-workers discussing DNS. I have often been told that after updating a DNS record takes no time at all, however the replication takes 48 to 72 hours. This is only true if DNS servers are cached. If a new request is made then the change that was just made will be readily available. Now we know how information is saved let’s take a look at the initial resolution. The resolver within DNS is on the client side. It will initiate the request for a search which will ultimately lead to the resolution of the domain name to an IP address. The resolver negotiates use of recursive service. For querying purposes, software interprets the name segment by segment, from right to left (Hosting PHP UNIX, 2006). At each step along the way, the program queries a corresponding DNS server to provide a pointer to the next server which it should consult. A user will never directly communicate with a resolver. The resolution is actually transparent to the user. When a user makes a request from a program, such as a web browser, it will contact the resolver. A resolver will check their cache and return if the information if it is available. If the resolver does not have the information requested then it will reach out to DNS servers. There are often times where a program will maintain a separate version of cached addresses. This prevents them from having to reach out as well. This can sometimes cause issues when trying to troubleshoot DNS issues. Though we have been mostly referencing the Internet when talking about DNS and name resolution it is not the only place it is used. On a network within a company there are usually DNS servers built. Administrators will configure workstations to point to the appropriate resolvers. When it comes to an Internet Service Provider (ISP) they will provide the DNS server or allow it to be set up through Dynamic Host Configuration Protocol (DHCP). Networks within organizations heavily rely on DNS especially when working with Active Directory. Active Directory is the directory service for the Microsoft Windows Server 2003 operating system; DNS is the primary name resolution service or Windows Server 2003, and a core component of Windows Server 2003 TCP/IP networking (TechNet, 2003). To fully understand Active Directory, it helps to understand how DNS acts as an integral component in the design of Active Directory. Active Directory requires a name resolution service that enables network hosts and services to locate Active Directory domain controllers and a naming structure that enables an enterprise to reflect its organizational structure in the names of its directory service domains. DNS provides Active Directory with both a name resolution service for domain controller location and a hierarchical design that Active Directory leverages to provide a naming convention that can reflect organizational structure. Typically, a DNS domain namespace deployed to accommodate the Active Directory mirrors the Active Directory domain namespace. In cases where there is an existing DNS namespace prior to Active Directory deployment, the DNS namespace is typically partitioned for Active Directory, and a DNS sub-domain and delegation for the Active Directory forest root is created. Additional DNS domain names are then added for each Active Directory child domain. DNS data is used to support the location of Active Directory domain controllers also. During or after the creation of the DNS zones used to support Active Directory domains, the zones are populated with DNS resource records that enable network hosts and services to locate Active Directory domain controllers. An Active Directory-integrated zone is a zone that stores its zone data in Active Directory. DNS zone files are not needed. This type of zone is an authoritative primary zone. Zone data of an Active Directory-integrated zone is replicated during the Active Directory replication process. Active Directory-integrated zones also enjoy the security features of Active Directory. A few advantages that Active Directory-integrated zone implementations have over standard primary zone implementations are speed, access, and replication. Active Directory replication is faster, which means that the time needed to transfer zone data between zones is far less. The topology is used for AD replication. There is no longer a need for DNS replication when DNS and AD are integrated. The need to manage AD domains and DNS namespaces as separate entities is eliminated. When DNS and AD are integrated the zones are replicated and stored on domain controllers automatically. Synchronization takes place automatically when new domain controllers are deployed. When there is a service as important as DNS on a network it is always a good idea to know the security risks. Though it is helpful and beneficial to any network, DNS has a number of security issues. DNS caching as explained earlier as a successful resolution response that remains valid on a server for a predetermined amount of time. One security threat is called cache poisoning. Cache poisoning is when a DNS server is led into believing that it has received valid information. Cache poisoning is often used to direct user request to another website. This can be done for commercial solicitation (advertisements) or for even more malicious reasons. An attacker can alter the cache to have unsuspecting users inadvertently connect to a server that is owned by the attacker. Once this connection is complete the attacker can spoof the intended server and in turn allow the user to download worms, viruses, etc. (CompSec101, 1999). A virus can cause IP addresses of that server to be redirected to a malicious address with a long TTL. This could have far-reaching impact to potentially millions of Internet users if busy DNS servers cache the bad IP data. This would require manual purging of all affected DNS caches as required by the long TTL. To prevent this from happening, an administrator can enable DNS cache pollution protection. This protection will ensure that servers acting as a parent in the child-parent relationship will not be poisoned when resolution requests are forwarded. Techniques such as Forward Confirmed reverse DNS can also be used to help validate DNS results. This is implemented by having both forward and reverse DNS entries matching each other. That is when only the IP address is known and a user is looking for the hostname. Besides caching an attacker can also affect zone transfers. DNS servers are often configured to provide other DNS servers with updates. A secondary server performs a zone transfer to retrieve DNS data from a primary server. An attacker can use the same method to obtain all information in a DNS zone. With this information an attacker can map an organization’s network. These threats are serious and can be detrimental to a network. However, there are ways to ensure that DNS is secure. The common rule of thumb is to block everything and then begin to select what types of traffic you will allow. If there is any time that a company wants remote users to have access to items on your network then a Demilitarized Zone (DMZ) should be created. The DMZ is an area outside the firewall (InterHack, 2009).
Many networks use a split DNS design to separate their publicly accessible DNS servers and the DNS servers that resolve names internally in an organization. This designs helps prevent attackers from gaining access to internal information. The common rule of thumb is to block everything and then begin to select what types of traffic you will allow. If there is any time that a company wants remote users to have access to items on your network then a Demilitarized Zone (DMZ) should be created. The DMZ is an area outside the firewall (InterHack, 2009). This is the perfect place for an external DNS server. An administrator can also limit zone transfers. This configuration has DNS servers only going to specific secondary servers. The DNS implementation in Windows 2000 and later allows a DNS server to authenticate the identity of a computer account that attempts a zone transfer. BIND, explained later, can be configured to require DNS updates from clients to be signed. Both of these methods can prevent unauthorized clients from updating DNS registrations. Last but certainly not least is the most basic security method that can be applied. Administrators should ensure that server software has the latest updates installed to prevent DNS poisoning. When talking about DNS you will at most times here the term BIND as mentioned above. BIND stands for Berkeley Internet Name Domain Server and is an implementation of a DNS Server (The Berkeley Internet Name Domain Server). Developed in the 80s by four graduate students, it is the most commonly used software today and is mainly used on UNIX systems. It is a standard way of naming the many types of objects and resources that exist in distributed UNIX environments, and provides operations for storing and retrieving information about these objects. BIND was under heavy fire for having an open source code and eventually led to the development of alternative name servers and resolver programs. BIND Servers collectively manage a hierarchical name space that is partitioned into domains reflecting administrative entities. BIND is programmed to check whether a DNS is server is valid or not. This can prevent DNS cache poisoning Finally there are some mentionable features of DNS that are very helpful to Internet as well as network users. Nslookup is the name of a program that lets an Internet server administrator or any computer user enters a host name (for example, "yahoo.com") and find out the related IP address. It will also do reverse name lookup and find the host name for an IP address you specify. Nslookup sends a domain name query packet to a designated DNS server. Using the Linux and other versions of nslookup, you can locate other information associated with the host name or IP address, such as associated mail services. Nslookup is included with some Unix-based operating systems and in later Windows systems. DNS is not only used to translate an IP address to a hostname and vice versa. There are many other functions that most users are unaware of. DNS can also be used to for mail delivery (MX records), blacklists (restricting IPs), and storage (software updates). DNS Based Blacklist is “a list of IP addresses published through the Internets DNS” (DNSBL wiki) that are linked to spamming. Mail servers can be configured to reject messages that have been sent from a site listed on the blacklist. DNS can also be implemented with Windows Internet Name System (WINS). WINS is a name server for NetBIOS computer names. WINS is to NetBIOS names as DNS is to domain names (Windows Internet Name Service, 2009). A multiple network platform can have a UNIX based server handle a NDS request and a Windows based server handle a WINS requests. DNS and WINS work together by translating NetBIOS names and host names to IP addresses. This connection allows you to resolve names to remote computers across a Local Area Network (LAN) and across the Internet. In conclusion, the Internet has many intricacies that most of us fail to realize. When information comes so fast it is easy to forget what actions have taken place in the background to provide us this service. As explained above DNS can be used for resolution, configurations, and protection. DNS may be quiet and operate in the background but it has become almost a foundation of the networks we have come to know and love. Without DNS we would basically be lost within the World Wide Web.

Bibliography

CompSec101. (1999). Cache Poisoning Attacks. Retrieved 19 July, 2009, from http://compsec101.antibozo.net/papers/dnssec/dnssec.html
DNS and BIND. (2000, September 17). DNS and BIND Talk Notes. Retrieved 02 August, 2009, from http://www.tfug.org/helpdesk/general/dnsnotes.html
Hosting PHP UNIX. (2006). DNS Components. Retrieved 29 July, 2009, from http://www.hosting-php-unix.com/dns_components.htm
InterHack. (2009, April 01). Internet Firewalls: Frequently Asked Questions. Retrieved July 17, 2009, from http://www.interhack.net/pubs/fwfaq/
MX Record. (2009, July 29). MX Record. Retrieved 06 August, 2009, from http://en.wikipedia.org/wiki/MX_record
TCP/IP Guide. (2005, September 20). DNS
Message Resource Record Field Formats. Retrieved 30 July, 2009, from http://www.tcpipguide.com/free/t_DNSMessageResourceRecordFieldFormats-2.htm
TechNet. (2003, March 28). DNS Support for Active Directory Technical Reference. Retrieved 03 August, 2009, from http://technet.microsoft.com/en-us/library/cc781627(WS.10).aspx
TechNet. (2003, March 28). What Is DNS Support for Active Directory. Retrieved 30 July, 2009, from http://technet.microsoft.com/en-us/library/cc757136(WS.10).aspx Terry, D., Pinter, M., Riggle, D., Zhou, S. (1984). The Berkeley Internet Name Domain Server. Computer Systems Research Group, Available: (http://www.eecs.berkeley.edu/Pubs/TechRpts/1984/CSD-84-182.pdf. (July 22, 2009 WindowsITPro. (2001, July). DNS and Active Directory. Retrieved 30 July, 2009, from http://windowsitpro.com/article/articleid/21128/dns-and-active-directory.html
Windows Internet Name Service. (2009, 23 July). Windows Internet Name Service. Retrieved 25 July, 2009, from http://en.wikipedia.org/wiki/Windows_Internet_Naming_Service