Domain Name System

Template:TOC-right In the Internet, the Domain Name System (DNS) is the service which translates to and from raw IP addresses and domain names. This allows web browsers and other client software to use more human-readable domain names such as "microsoft.com" instead of an address such as "192.168.1.1". DNS is both a distributed database and set of application protocols, with the original purpose of translating from human-readable domain names to Internet protocol (IP) addresses (i.e., forward DNS) and from addresses to names (i.e., reverse DNS).

Over the years, it has taken on more technical and administrative roles. The domain name space, as well as the address spaces both for Internet Protocol version 4 and Internet Protocol version 6 (IPv6) are under the authority of the Internet Corporation for Assigned Names and Numbers (ICANN), with much delegation of administration. The original system only handled IPv4, so one of the first steps for IPv6 support was defining how to represent IPv6 addresses in DNS. Berkeley Internet Name Domain (BIND), first deployed in BSD 4.3 UNIX and written by Kevin Dunlap, was the first widespread DNS implementation. BIND is now public domain code supported by the Internet Systems Consortium .

In the years DNS has served, Internet technology and operational issues change. When the new IPv6 adddress format came into use, the need to change name-to-address mapping tools to handle that format is understandable.

Less obvious, but still necessary, is the new requirement to have a capability to track dynamically assigned addresses when there is no central address server. Domain Name System dynamic update can can do such tracking, but dynamic update at this level is a security vulnerability. Address assignment spoofing is, by no means, the only threat to DNS, and an entire set of Domain Name System security (DNSSEC) are being deployed.

History

DNS was first introduced for use on the internet in 1983, with the first specification written by Paul Mockapetris. Mockapetris' first DNS implementation was called JEEVES, and replaced the ARPANET (pre-Internet) environment with few enough computers that a single file, hosts.txt, was sufficient to contain all connected computer names and their numeric addresses. Its designers, however, did not think of it as anything like a search engine, with the ability to seek a name corresponding to an idea (e.g. "pizza"), but to work with explicit names already known by the application. Sharing hosts files manually quickly became impossible to scale as the Internet grew, and DNS was designed and implemented as the solution to the problem of scalable host name resolution.

Later roles for DNS include providing additional information for the names and addresses, especially for security; the DNS infrastructure itself needed to be enhanced to be secure and trusted. DNS originally was manually configured, but there have needed to be a variety of extensions to allow dynamic operation, such as the temporary binding of an address to a name.

Operationally, it was always expected that populating the Domain Name System data base would be cooperative.

Protocol designers	Name & address authorities	System administrators
Standard formats for resource data.	Addresses for the root servers	The definition of zone boundaries
Standard methods for querying the database	Unique assignments of domain names	Master files of data (i.e., sets of Resource Records (RR)
Standard methods for name servers to refresh local data from foreign name servers.	Operation, perhaps with delegation of the root servers and top-level domain servers	Statements of the refresh policies desired

Domain name structure and schema

Domain Name System tree section

The DNS namespace is hierarchical. Individual domain and host names within it have a textual representation, from right to left, which mirrors the tree that makes up the schema of the DNS:

en.citizendium.com

appears to have three components, but actually has four. The naming hierarchy is a tree, with increasingly specific levels reading right to left.

From what can be seen in the textual example,

• .com is a top-level domain (TLD) under the authority of a TLD registry.
• .citizendium is a second-level domain under the authority of a SLD registry (SLD)
• .en identifies either a subdomain or a host, as defined by the citizendium.com technical administrator.

What cannot be seen is the hierarchically "zeroth" highest part, the root. If a part usually suppressed were displayed,

en.citizendium.com.

The rightmost dot identifies the root of the DNS tree. In actual practice, there are multiple root servers, for which addresses are in an explicit file, a representative of whih is found at http://www.internic.net/zones/named.root

It is defined as:

This file holds the information on root name servers needed to initialize cache of Internet domain name servers (e.g. reference this file in the "cache . <file>" configuration file of BIND domain name servers).

A fully qualified domain name can be traced from the hierarchically lowest host name to the root. For example, en.citizendium.org goes from the host en all the way up to the top-level domain .org, which is connected to the root.

A computer within the second-level domain citizendium.org could refer to the subdomainen, which would be a relative domain name; most DNS applications would append the current domain to the right of the host name. k12.en.citizendium.org is a hypothetical subdomain of en.citizendium.org; an arbitrary host could be larry.en.citizendium.org and the DNS software would understand if it is dealing with a host or a domain.

Name servers and zone files

A [sub]domain is a name space that need not have names in it. The basic source of name information that goes into a particular space is a zone file, created manually or with software assistance.

Populating a primary name server

Just as the DNS namespace is a tree of domains, the actual information in that namespace can be regarded as a tree of zone files.

Name servers are computers that contain information about domains, all the way up to the root. Be sure to understand the difference between the abstraction of a domain or subdomain namespace, and the zone file that describes the contents of that namespace and actually runs in a name server. The primary name server is authoritative for domains, and contains the master copy of the zone file for that domain.

Name servers can contain more than one zone file; indeed, this is the usual case when there are domains with subdomains.

Depending on the implementation, a name server may cache information in addition to what it learned from the zone file. For example, a local cache file in a name server could contain data about name-address relationships outside the domain, but which have been needed by a client within that domain. The name server may also contain limited-lifetime dynamic name updates, which might or might not be accessible from outside the domain.

Domains versus zones

At each of these levels is an abstract namespace. No other second-level domain could have notcz.citizendium.com, but the administrator of citizendium.com is not obligated to have any number of subordinate hosts or domains. There is a subtle distinction between the abstraction of a name space, and a zone file that actually defines the hosts and subdomains in the zone.

Domain naming administration and issues

Name assignment

The administrative process of DNS name assignment involves both DNS registries and DNS registrars

DNS registries

DNS registries' fundamental role is to operate the data base for their top-level domain, and authorize registrars as "retail" agents to provide customer service.

Top-level domain	Registry	Comments
.com	Verisign
.edu
.net
.mil	Defense Information Systems Agency
.org	Public Interest Registry (PIR)
.biz	NeuLevel, Inc.
.us	NeuStar, Inc.
.ca	Canadian Internet Registration Authority (CIRA)

Basic Implementation

The administrator starts by building a zone file that defines the names and addresses of hosts in that zone, optional additional information to be added to the responses, and to a higher-level nameserver that helps connect the domain of the zone to other domains. For example, if one was in a.com , one would have to go to the nameserver of .com to find the address of the b.com nameserver.

This information goes into resource records (RR), of which the basic types are:

• Start of authority (SOA) Define the start of the zone file and the domain it describes.
• Name server (NS): gives the IP address of a hierarchically higher name server to which the name server goes when it cannot complete a name-to-address or address-to-name mapping based on its own information.
• Address (A): map a name to an IP address. Basic A records deal with 32-bit Internet Protocol version 4 addresses, while AAAA records handle 128-bit Internet Protocol version 6.
• Pointer (PTR): do the reverse mapping of an address to a name.

A and PTR records, in particular, have Time to Live (TTL) fields, which tell caches how long they can be retained and still assumed to be accurate. Especially when DNS Security (DNSSEC) is supported, other RRs will be present.

The root name server zone file is expected to be retrieved, by anonymous FTP, from various well-known sites approved by ICANN. In practice, most DNS implementations ship with a recent copy. Root servers remain very busy. If fact, while the root server zone file mentioned above will give the names and addresses of root servers in the general form a.root-servers.net, the address of a particular server is of the anycast type; there are multiple physical computers with that address, for fault tolerance and load sharing.

For each domain, there must be at least one, and preferably more than one name server that holds the zone files. Primary domain servers have the authoritative zone files, and secondary domain servers keep an exact copy of the primary's zone file. Both types are assumed to have a disk or other storage from which they can restore the domain information.

Zone transfer adds to populating a server database

A secondary server will use a zone transfer to obtain the primary zone file for its domain. There are various operational reasons why a physical server might act as primary and secondary for multiple zones; the important point here is that a zone transfer, as opposed to ordinary DNS retrieval, alters the contents of the definitions and must be treated as a sensitive operation.

Adding trusted dynamic updates

The nameserver also can take dynamic transfers, which, strictly speaking, do not have to be secured, but dynamic update, especially in a IPv6 environment, is so open an invitation to miscreants that it should never be considered without being secured. DNS security is the normal way this might be done, but there are other alternatives, such as an encrypted link between the update source and the nameserver.

There are also caching-only servers that contain only the names and addresses that have been recently looked up, and are still valid with respect to the TTL parameter in the relevant records.

The program, on a host, which is the client of DNS servers is most often called a resolver. Depending on the local network architectural implementation, a resolver may go to a caching-only server, a secondary server, or the primary server for its information. It may retain a cache of recently retrieved DNS information, clearing items from cache as their TTLs expire.

DNS security architecture

DNS, as a critical part of the Internet infrastructure, needs to be protected. There have been, and continue to be, serious attacks against it. DNS software and operations should follow the overall DNS security architecture (DNSSEC).

DNS can and should be updated with dynamically acquired addresses.

The U.S. government is requiring DNSSEC for all Federal information systems by December 2009.

DNS protocols

The most basic DNS protocols are the lookup service, which runs over port 53 of the connectionless User Datagram Protocol, and the zone transfer service, which also runs over port 53 of the connection-oriented Transmission Control Protocol. Lookup is a read-only function, while zone update is read-write and should be implemented as a privileged, authenticated operation. Otherwise any client on a DNS server's network could request a zone transfer, and receive a complete copy of a zonefile, which is a security risk.

There are also protocols for dynamic update, so that network clients can automatically update their DNS servers t reflect correct hostnames (e.g. if they dynamically receive a different IP address via DHCP). This concept is also known as Dynamic DNS.

Extended applications

These include Domain Name System dynamic update, use of the DNS as a data base in Public Key Infrastructure for security, Domain Name System security (DNSSEC) and name-based routing and load distribution.