DNS and Active Directory

Chapter 2.1 The Domain Name Service from Wu-Irwin Text

2.1 The Domain Name Service (DNS)

Section 2.1.1 through 2.1.4

2.1.1 Overview

The DNS is a critical service run by a myriad of Internet Service Providers (ISPs), organizations, and Internet authorities throughout the world to facilitate the resolution of domain names to Internet Protocol (IP) addresses that users can employ to connect to resources.

In the same manner, Internet hosts and routers are identified by a 32-bit IP address that is used for addressing datagrams. While this method is certainly accurate, it is not convenient.

As a result, we need a method to map between an IP address and the corresponding name. Because the Internet space is absolutely massive in size, a well-developed system is needed to accomplish this function.

This system is the DNS, and it is a distributed database implemented in a hierarchy consisting of numerous name servers. It is also an application-layer protocol, defined by RFCs 1034 [1] and 1035 [2], that permits hosts to communicate in order to resolve the IP address/name translation.

Note that this core Internet function of the DNS is implemented as an application-layer protocol for querying the distributed database, and since the IP address is often cached at a DNS server in close proximity, complexity is typically at the network’s edge.

The distributed, hierarchical nature of the DNS is shown in Figure 2.1. Because of the staggering number of hosts in the Internet, a large number of servers, organized in a hierarchical structure and resident throughout the globe, are employed by the DNS. The structure of the worldwide DNS server network is organized in a manner similar to that shown in Figure 2.1. This server structure consists of three levels, (1) a root server, (2) top-level domain (TLD) servers and (3) authoritative servers.

Example 2.1: The Process Employed by a Host to Query the DNS Hierarchy

The functions of each level in the distributed hierarchical nature of DNS can be seen via a simple example in which a client host inside auburn.edu wants to obtain the IP address for the hostname www.cnn.edu as shown in Figure 2.1. First the local DNS server (dns.auburn.edu) for the client host queries the root server to locate the.com TLD DNS server if the name resolution is not in its cache. The local DNS server then queries the.com TLD DNS server to reach the cnn.com DNS server. Finally, the local DNS server queries the cnn.com’s DNS server to obtain the IP address for www.cnn.edu.

Thirteen organizations manage the Root Name Servers, located in multiple sites worldwide, as shown in Table 2.1. The root name servers sit at the top of the hierarchical structure, and are used in the following manner. Suppose a host wants to obtain a particular IP address. The host sends a DNS query message to its local DNS server, typically resident in each company, university or ISP. If this local DNS server cannot obtain the name from its cache, it sends the query to the root name DNS server. The root name DNS server sends the local DNS server the IP addresses of the Top-Level Domain (TLD) DNS server that handles that domain. The local DNS server then contacts one of the TLD DNS servers. The TLD server then sends the local DNS server the IP address for the Authoritative DNS server that handles the domain for the particular host. Finally, the local DNS server can now obtain the IP address desired and deliver a DNS response to the host that initiated the query.

Worldwide Root Name Servers

Operator	Locations	IP Addresses
VeriSign, Inc.	Dulles VA	1Pv4: 198.41.0.41Pv6:2001:503:BA3E::2:30
Information Sciences Institute	Marina Del Rey CA	1Pv4: 192.228.79.2011Pv6: 2001:478:65::53
Cogent Communications	Herndon VA; Los Angeles; New York City; Chicago	192.33.4.12
University of Maryland	College Park MD	128.8.10.90
NASA Ames Research Center	Mountain View CA	192.203.230.10
Internet Systems Consortium, Inc.	43 sites:Ottawa; Palo Alto; San Jose CA; New York City; San Francisco; Madrid; Hong Kong; Los Angeles; Rome; Auckland; Sao Paulo; Beijing; Seoul; Moscow; Taipei; Dubai; Paris; Singapore; Brisbane; Toronto; Monterrey; Lisbon; Johannesburg; Tel Aviv; Jakarta; Munich; Osaka; Prague; Amsterdam; Barcelona; Nairobi; Chennai; London; Santiago de Chile; Dhaka; Karachi; Torino; Chicago; Buenos Aires; Caracas; Oslo; Panama; Quito	1Pv4: 192.5.5.2411Pv6: 2001:500:2f::f
U.S. DOD Network Information Center	Columbus OH	192.112.36.4
U.S. Army Research Lab	Aberdeen MD	1Pv4: 128.63.2.531Pv6:2001:500:1::803f:235
Autonomica/NO RDUnet	31 sites:Stockholm; Helsinki; Milan; London; Geneva; Amsterdam; Oslo; Bangkok; Hong Kong; Brussels; Frankfurt; Ankara; Bucharest; Chicago; Washington DC; Tokyo; Kuala Lumpur; Palo Alto; Jakarta; Wellington; Johannesburg; Perth; San Francisco; New York; Singapore; Miami; Ashburn (US); Mumbai; Beijing; Manila; Doha	192.36.148.17
VeriSign, Inc.	41 sites:Dulles (3 locations), Vienna, Miami, Atlanta, Seattle, Chicago, New York, Los Angeles, Mountain View, San Francisco (2 locations), Dallas (US); Amsterdam (Nl); London (UK); Stockholm (2 locations) (SE); Tokyo (JP); Seoul (KR); Bejing (CN); Singapore (SG); Dublin (IE); Kaunas (l T); Nairobi (KE); Montreal, Quebec (CA); Sydney (AU); Cairo (EG); Warsaw (Pl); Brasilia, Sao Paulo (BR); Sofia (BG); Prague (CZ); Johannesburg (SA); Toronto (CA); Buenos Aries (AR); Madrid (ES); Vienna (AT); Fribourg (CH); Hong Kong (HK); Turin (IT)	1Pv4: 192.58.128.301Pv6:2001:503:C27::2:30
Reseaux IP Europeens • Network Coordination Centre	17 sites:London (UK); Amsterdam (Nl); Frankfurt (DE); Athens (GR); Doha (QA); Milan (IT); Reykjavik (IS); Helsinki (FI); Geneva (CH); Poznan (Pl); Budapest (HU); Abu Dhabi (AE); Tokyo (JP); Brisbane (AU); Miami (US); Delhi (IN); Novosibirsk (RU)	1Pv4: 193.0.14.1291Pv6: 2001:7fd::1
Internet Corporation for Assigned Names and Numbers	Los Angeles (US); Miami(US)	1Pv4: 199.7.83.421Pv6: 2001:500:3::42
WIDE Project	6 sites:•Tokyo (JP); Seoul (KR); •Paris (FR);	1Pv4 : 202.12.27.331Pv6: 2001:dc3::35

As the name implies, the top-level domain servers are responsible for the “top-level” domains, which consist of not only the familiar domains, such as those for companies, educational institutions and government, e.g., com, edu and gov, respectively, but those for countries as well, e.g., es and jp for Spain and Japan, respectively. Clearly, some entity has to keep track of these domains. The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing the assignment of these various domain names and IP addresses. This corporation works in conjunction with other entities that manage subsets of these domains. For example, com and edu are managed by Network Solutions and Educause, respectively. A listing of TLD name servers is given below.

.edu TLD
a.gtld-servers.net.	192.5.6.30	2001:503:a83e:0:0:0:2:30
c.gtld-servers.net.	192.26.92.30
……….
.com TLD
a.gtld-servers.net.	192.5.6.30	2001:503:a83e:0:0:0:2:30
b.gtld-servers.net.	192.33.14.30	2001:503:231d:0:0:0:2:30
c.gtld-servers.net.	192.26.92.30
……….
.org
a0.org.afilias-nst.info.	199.19.56.1	2001:500:e:0:0:0:0:1
b0.org.afilias-nst.org.	199.19.54.1	2001:500:c:0:0:0:0:1
……….
.fr TLD
a.nic.fr.	192.93.0.129	2001:660:3005:3::1:1
c.nic.fr.	192.134.0.129	2001:660:3006:4:0:0:1:1
……….

The third column is the IPv6 address. The source for this listing is [3][4].

Every organization, with hosts connected to the Internet, has at least one authoritative DNS server that provides authoritative hostname-to-IP address mappings for their organization, such as mail servers and Web servers. These authoritative DNS servers can be maintained by the organization or some ISP.

2.1.2 Recursive and Iterative Queries

There are two types of DNS queries: (1) recursive and (2) iterative.

Suppose now that a host requests a specific IP address. In the recursive mode, the request is handled by the local DNS server and traverses the path that runs through the local DNS server, the root DNS server, the TLD DNS server to the Authoritative DNS server, and back again. The IP address is provided to the host by the local DNS server.

Now suppose that a host at auburn.edu wants the IP address for www.mit.edu as shown in Figure 2.2. If the Resource Record (RR) is not in the cache of the local DNS server, then the local DNS server will carry out the recursive query for the local client. DNS.auburn.edu, as the local DNS server, performs the recursive query for the host in its role as the recursive/caching name server. Recursive queries are only served for hosts in the same domain in order to reduce the load.

The iterated, i.e., non-recursive, queries are shown as Arrows 2, 3, and 4, e.g., root DNS replies to dns.auburn.edu and asks it to contact the .edu TLD DNS server.

The iterative operations, shown in Figure 2.2, are handled by the root DNS server, then the TLD DNS server and finally the authoritative DNS server of ns.mit.edu. Once the requested information is obtained, it is returned to the requesting host. The ns.mit.edu plays the role of an authoritative name server that contains the very original copy of the RRs for the mit.edu domain.

These authoritative DNS servers, also known as master servers, contain the original set of data. In addition, a secondary or slave name server may contain data copies that are normally obtained from direct synchronization with the master server. It is recommended in RFC 2182 [5] that three servers be provided for most organizations operating in the iterative mode. The IP addresses for the authoritative DNS servers are maintained by ICANN, and resident in the TLD DNS servers.

2.1.3 Recursive or Caching DNS Server

Although it does not strictly belong to the DNS hierarchy of servers, the local DNS server is a critical component in this vast architecture. This server, also known as the default name server, is resident in each company, university, or local ISP. So, when a host makes a DNS query, this query is sent directly to the local DNS server, which acts as a proxy and forwards the query into the DNS hierarchy for processing in the recursive mode.

Inside a host, a process known as DNS resolver is employed to map from a name to an IP address. These resolvers are simply programs that obtain information from name servers in response to client requests. A cache preserves the mapping for a certain length of time. A DNS resolver can be running within any computer that serves as a

• Client computer
• Web server, Mail server, etc.
• DNS server

Resolvers must have access to at least one name server and use that name server’s information to answer a query directly, or perform the query through referrals to other name servers.

The terms recursive server and caching server are often used synonymously as in the Berkeley Internet Name Domain (BIND), which is the most commonly used DNS implementation in the Internet. A typical implementation might move the resolver function out of the local machine and into a name server, which supports recursive queries. This process produces an easy method for providing domain service for a PC which lacks the resources to perform the resolver function, or can be used to centralize the cache for a whole local network. Each PC should have a list of name server addresses that will perform the recursive requests on its behalf.

A caching name server does not necessarily perform the complete recursive lookup itself. Instead, it can forward some or all of the queries it cannot answer from its cache to another caching name server, commonly referred to as a Forwarder. Caching servers that are unable to pass packets through the firewall would forward to a server that can, and that server would query the Internet DNS servers on behalf of the caching server [6].

Example 2.2: A Home Network’s Caching/Recursive DNS Server

Routers that connect a home network to a DSL/cable modem provide caching/recursive name service. For example, 192.168.1.1 is the LAN interface that provides caching DNS, and some routers may use 192.168.x.1, where x ranges from 0 to 255. Some vendors refer to this function as DNS relay.

Figure 2.3 illustrates the DNS hierarchy in a particular zone, and provides an overview of the relationship among the primary authoritative, secondary authoritative and recursive servers. As Figure 2.3 indicates, tracking down the name of a host for a client is a recursive process with several steps. Suppose that after this process is complete another host requests the same information. Since this information was just obtained, it would be very inefficient to repeat all the same steps again to retrieve the same information. In order to shortcut this process and prevent this repetition, once a DNS server learns a mapping it caches it in its local memory. Now when another query arrives for the same information that was recently obtained, it is readily available.

These mappings are not stored forever and typically disappear after some preset timeout period. However, this caching process ensures that the search is conducted at the lowest level in the hierarchy, and as a result root name DNS servers are not constantly in the loop. TLD servers are typically cached in a local name server (such as dns.auburn.edu), which can be an authoritative or recursive name server. Thus root and TLD name servers are not often visited. For example, the time to live (TTL) for the .com gTLD is two days and thus a local DNS server would only have to visit a root server once every two days in order to obtain the current list of .com gTLD servers [7]. The updating and notification mechanisms, associated with the caching process, were designed by the Internet Engineering Task Force (IETF) and are listed in RFC 2136 [8].

Within the DNS server hierarchy the recursive servers, often referred to as DNS caches or caching-only name servers, function to provide DNS name resolution for computers in the same domain. They relay client application requests to the authoritative name server structure to fully resolve a network name. Once the data is obtained, they cache the information in order to answer potential future queries within some fixed (expiration) period. Servers that provide Recursion Access Control (RAC) maintain control over hosts, which are permitted to use DNS recursive lookups, in order to reduce the computation and communication load. If a server is going to provide caching services, then it must provide for recursive queries. A local name server can be an authoritative server, a recursive name server, or both.

Because of the strategic function that DNS provides, reliability is critical. One method employed to mitigate risk is the use of redundancy in which the DNS is divided into two servers, one of which is the primary and the other is secondary. Then loss of the primary server does not constitute loss of the DNS function. In addition, it may be prudent to let only local users that are part of the domain to query the sensitive part of the DNS to ensure the confidentiality of the naming conventions and other sensitive information.

DNS uses the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port number 53 for lookups and transfers. TCP port 53 comes into play only when the response data size exceeds 512 bytes, or for tasks such as a zone transfer from primary authoritative to secondary authoritative server. The port must be opened on the firewall if the internal DNS is required for lookups through a VPN. Since DNS uses UDP port 53 for lookups, this port should be opened to the virtual private network (VPN) through the firewall if a remote user requires use of the internal/private DNS for lookups. It is important to note that this decision will be defined in the planning phase and should be used with a VPN. This lookup decision should be made early and carefully calculated for both the firewall and the risk to a VPN. If necessary, it is wise, especially from a security perspective, to publish only the minimum services in the public domain DNS.

Recursive queries need access to the root servers, which are provided via the ‘type hint’ statement in the DNS configuration and root servers’ IP addresses are in a file with the name root.servers:

• type hint;

• file “root.servers”;

2.1.4 The Resource Record (RR) and DNS Query

The Resource Records (RRs) contain the information requested by DNS queries, and this data is stored in a universal format which has been dictated by RFCs 1034 [1] and 1035 [2]. The details of this information are outlined in the following material.

2.1.4.1 The RR Format

Within the DNS hierarchy, each time a DNS server replies to a query the response contains one or more of what are called Resource Records (RRs). These records contain the name resolution information. The formats employed for these resource records are

• (name, [pref.], value, type, [TTL])
• name [TTL][Class] Type [pref.] value

where TTL is Time To Live and pref is the Preference value. Format 1 is used only for illustrations in this book due to its simplicity, while Format 2 is the one actually used by BIND DNS servers. Both formats carry the same information with the notable exception of Class. TTL is the lifetime of the cached RR and a 32-bit unsigned integer with units of seconds. The value zero indicates the data should not be cached. The TTL, Class and pref are optional. Omitted class and TTL values default to the last explicitly stated values.

The name and value in this format depend on type. There are four “Types” defined as follows:

Type = A

• Name is the hostname

• Value is the IP address

(This type is simply a hostname-to-IP address mapping)

Type = NS

• Name is the domain, e.g., auburn.edu

• Value is the hostname of the authoritative name server for this domain

(This type is used as a routing function for queries)

Type = CNAME

• Name is the alias name, e.g., www.ibm.com

• Value is the canonical name, e.g., servereast.backup2.ibm.com

(This type simply provides the canonical name when requested)

Type = MX

• Name is domain name

• Value is the name of the mail server associated with this domain

A preference value is designated for each mail server if there are multiple MX RRs in a domain. When there are multiple MX RRs available, the mail server with the smallest Preference value is used. No CNAME RR is allowed for multiple mail servers.

At present, the Class in Format 2 is typically used to indicate the Internet system.

Class (16 bit) = IN

• Class identifies a protocol family or instance of a protocol and is the Internet system (IN) for the Internet.