Domain Name System
In the Internet, the Domain Name System (DNS) is a relatively old service, with the first specification, by Paul Mockapetris, going back to 1983.[1] The first DNS implementation, written by Mockapetris, 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.[2] 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.
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 [3].
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). [4] 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. [5]
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. [6] 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.comappears 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.comtechnical 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).
Name servers
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.
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. [2]
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.
- anycast
- FQDN
- relative domain name
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.[7] 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. [8]
References
- ↑ Mockapetris, P.V. (November 1983), Domain names: Concepts and facilities, Internet Engineering Task Foce, RFC882
- ↑ 2.0 2.1 Albitz, Paul & Cricket Liu (1997), DNS and BIND, second edition, O'Reilly p. 9
- ↑ http://www.isc.org/index.pl
- ↑ Mockapetris, P.V. (November 1987), Domain names - concepts and facilities, Internet Engineering Task Force, RFC1034
- ↑ Bush, R. et al. (August 2002), Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS), Internet Engineering Task Force, RFC3363
- ↑ Arends, R. et al. (March 2005), DNS Security Introduction and Requirements, Internet Engineering Task Force, RFC4033
- ↑ Mockapetris., P.V. (November 1987), Domain names - implementation and specification, Internet Engineering Task Force, RFC1035
- ↑ Vixie, P., ed. (April 1997), Dynamic Updates in the Domain Name System (DNS UPDATE), Internet Engineering Task Force, RFC2136