Domain Name System: Difference between revisions
imported>Howard C. Berkowitz (Work in progress) |
imported>Howard C. Berkowitz (zones and domains) |
||
| Line 48: | Line 48: | ||
Domain names are hierarchical. A name such as | Domain names are hierarchical. A name such as | ||
<center><code>en.citizendium.com</code></center> | <center><code>en.citizendium.com</code></center> | ||
appears to have three components, but actually has four. The naming hierarchy is a tree, with increasingly specific levels reading right to left. | 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, | From what can be seen in the example, | ||
| Line 64: | Line 64: | ||
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. | 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. | ||
===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. | |||
Fir 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. | |||
*roots | *roots | ||
| Line 73: | Line 75: | ||
*relative domain name | *relative domain name | ||
*primary zone server | *primary zone server | ||
==Domain naming administration and issues== | ==Domain naming administration and issues== | ||
Revision as of 19:51, 3 July 2008
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). [1] 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. [2]
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. [3] 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).
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.
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.
Fir 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.
- 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.[4] 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. [5]
References
- ↑ 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