Domain Name System: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(zones and domains)
imported>Alexander Wiebel
Line 67: Line 67:
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.
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.  
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.  


*roots
*roots

Revision as of 05:41, 4 July 2008

This article has a Citable Version.
 Main Article
 Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
https://en.citizendium.org/wiki/index.php?title=Domain_Name_System&printable=yes
This editable Main Article has an approved citable version (see its Citable Version subpage). While we have done conscientious work, we cannot guarantee that this Main Article, or its citable version, is wholly free of mistakes. By helping to improve this editable Main Article, you will help the process of generating a new, improved citable version.

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

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.

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.

  • 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

  1. ↑ Mockapetris, P.V. (November 1987), Domain names - concepts and facilities, Internet Engineering Task Force, RFC1034
  2. ↑ Bush, R. et al. (August 2002), Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS), Internet Engineering Task Force, RFC3363
  3. ↑ Arends, R. et al. (March 2005), DNS Security Introduction and Requirements, Internet Engineering Task Force, RFC4033
  4. ↑ Mockapetris., P.V. (November 1987), Domain names - implementation and specification, Internet Engineering Task Force, RFC1035
  5. ↑ Vixie, P., ed. (April 1997), Dynamic Updates in the Domain Name System (DNS UPDATE), Internet Engineering Task Force, RFC2136
Retrieved from "https://citizendium.org/wiki/index.php?title=Domain_Name_System&oldid=496654"