Domain Name System

In the Internet, the Domain Name System (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.

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).

The root name server 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.

• roots
• root server
• anycast
• FQDN
• relative domain name
• primary zone server

Domain naming administration and issues

Name assignment

• registry
• registrars

Implementation

• secondary zone server
• caching-only server
• 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.