Domain Name System

In the Internet, the Domain Name System (DNS) is the service which translates between 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 .

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.

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 names are hierarchical. A name such as

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 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 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 computer test-en, which would be a relative domain name; most DNS applications would append the current domain to the right of the host name.

Name servers and 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. Name servers can contain more than one zone file; indeed, this is the usual case when there are domains with subdomains.

Resource records

Zone files, minimally, contain four kinds of resource record, of which the basics 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.

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.

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

• registry
• registrars

Implementation

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.

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 time to live (TTL) parameter in the relevant records.

The program, on a host, which is the client of DNS servers is most often called a resolver.

DNS protocols

The most basic DNS protocols are the lookup service, which runs over the connectionless User Datagram Protocol, and the zone transfer service, which runs over 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.

There are also protocols for dynamic update.