About Opentopia
Opentopia Directory Encyclopedia Tools

Domain name system

Encyclopedia : D : DO : DOM : Domain name system

The domain name system (DNS) is a system that stores and associates many types of information with domain names, but, most importantly, it translates domain names (computer hostnames) to IP addresses. It also lists mail exchange servers accepting e-mail for each domain. In providing a worldwide keyword-based redirection service, DNS is an essential component of contemporary Internet use.

Useful for several reasons, the DNS is most well-known for making it possible to attach easy-to-remember domain names (such as "wikipedia.org") to hard-to-remember IP addresses (such as 207.142.131.206). Humans take advantage of this when they recite URLs and e-mail addresses. Less recognized, the domain name system makes it possible for people to assign authoritative names, without needing to communicate with a central registrar each time.

Contents

A brief history of the DNS

The practice of using a name as a more human-legible abstraction of a machine's numerical address on the network predates even TCP/IP, all the way back to the ARPAnet era. Originally, each computer on the network retrieved a file called HOSTS.TXT from SRI (now SRI International) which mapped an address (eg. 192.0.34.166) to a name (eg. www.example.net.) The Hosts file still exists on most modern operating systems either by default or through configuration and allows users to specify an IP address to use for a hostname without checking the DNS. This file is now used primarily for troubleshooting DNS errors or mapping local addresses to more organic names (the Hosts file can also be used for ad blocking, or it can be used by spyware to hijack a computer). Such a system had inherent limitations, because of the obvious requirement that every time a given computer's address changed, every computer that wanted to communicate with it would need an update to its Hosts file.

The growth of networking called for a more scalable system: one that recorded a change in a host's address in one place only. Other hosts would learn about the change dynamically through a notification system, thus completing a globally accessible network of all hosts' names and their associated IP Addresses. Enter the DNS. Paul Mockapetris invented the DNS in 1983; the original specifications appear in RFC 882 and 883. In 1987, the publication of RFC 1034 and RFC 1035 updated the DNS specification and made RFC 882 and RFC 883 obsolete. Several more recent RFCs have proposed various extensions to the core DNS protocols.

Mockapetris wrote the first implementation of DNS. The following year (1984), four Berkeley students made the first Unix implementation. They were Douglas Terry, Mark Painter, David Riggle and Songnian Zhau. Ralph Campbell did maintenance of Terry et al's work after that. In 1985, Kevin Dunlap of Digital Equipment Corporation did a major rewrite of the DNS implementation and renamed it BIND. BIND has since been under maintenance of Mike Kavels, Phil Almquist and Paul Vixie. BIND was also ported on to Windows NT platform in early 90s.

How the DNS works in theory

The domain name space is a tree of domain names. Each node or leaf in the tree is associated with resource records, which hold the information associated with the domain name. The tree is divided into zones. A zone is a collection of connected nodes that are authoritatively served by an authoritative DNS nameserver. (Note that a single nameserver can host several zones.)

When a system administrator wants to let another administrator control a part of the domain name space within his or her zone of authority, he or she can delegate control to the other administrator. This splits a part of the old zone off into a new zone, which is served by the second administrator's nameservers. The old zone is no longer authoritative for what is under the authority of the new zone.

The information associated with nodes is looked up by a resolver. A resolver knows how to communicate with name servers by sending DNS requests, and heeding DNS responses. Resolving usually entails recursing through several name servers to find the needed information.

Some resolvers are simple, and can only communicate with a single name server. These simple resolvers rely on a recursing name server to perform the work of finding information for them.

Understanding the parts of a domain name

A domain name usually consists of two or more parts (technically labels), separated by dots. For example wikipedia.org. The DNS consists of a hierarchical set of DNS servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains "beneath" it. The hierarchy of authoritative DNS servers matches the hierarchy of domains. At the top of the hierarchy stand the root servers: the servers to query when looking up (resolving) a top-level domain name.

The address resolution mechanism

(In this description the fictional .example TLD is used deliberately in accordance with the DNS guidelines themselves.)

In theory it is possible for a full host name to have several name segments, (e.g ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, in the experience of the majority of public users of Internet services, full host names will frequently consist of just three segments (ahost.inadomain.example, and most often www.inadomain.example).

For querying purposes, the name is interpreted segment by segment, right to left, using an iterative search procedure. At each step along the way, the corresponding DNS server is queried to provide a pointer to the next which should be consulted.

As originally envisaged, the process was as simple as:

  1. the local system is pre-configured with the known addresses of the root servers in a file of root hints, which need to be updated periodically by the local administrator from a reliable source to be kept up to date with the changes which occur over time.
  2. query one of the root servers to find the server authoritative for the next level down (so in the case of our simple hostname, a root server would be asked for the address of a server with detailed knowledge of the example top level domain).
  3. querying this second server for the address of a DNS server with detailed knowledge of the second-level domain (inadomain.example in our example).
  4. repeating the previous step to progress down the name, until the final step which would, rather than generating the address of the next DNS server, return the final address sought.
The diagram illustrates this process for the real host www.wikipedia.org.

The difficulty with the mechanism in this simple form is that it places a huge operating burden on the collective of root servers, with each and every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice there are two key additions to the mechanism.

These additions to the mechanism are discussed in greater detail later.

Circular Dependencies and Glue Records

Name servers in delegations are listed by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. Since this can introduce a circular dependency if the nameserver referred to is under the domain that it is authoritative of, it is occasionally necessary for the nameserver providing the delegation to also provide the IP address of the next nameserver. This record is called a glue record.

For example, assume that the sub-domain en.wikipedia.org contains further sub-domains (such as something.en.wikipedia.org) and the authoritative nameserver for these is at ns1.en.wikipedia.org. A computer trying to resolve something.en.wikipedia.org will thus first have to resolve ns1.en.wikipedia.org. Since ns1 is also under the en.wikipedia.org subdomain, resolving ns1.en.wikipedia.org requires resolving ns1.en.wikipedia.org which is exactly the circular dependency mentioned above. The dependency is broken by the glue record in the nameserver of wikipedia.org that provides the IP address of ns1.en.wikipedia.org directly to the requestor, enabling it to bootstrap the process by figuring out where ns1.en.wikipedia.org is located.

DNS in practice

When an application (such as a web browser) tries to find the IP address of a domain name, it doesn't necessarily follow all of the steps outlined in the Theory section above. We will first look at the concept of caching, and then outline the operation of DNS in "the real world."

Caching and time to live

Because of the huge volume of requests generated by a system like the DNS, the designers wished to provide a mechanism to reduce the load on individual DNS servers. The mechanism devised provided that when a DNS resolver (i.e. client) received a DNS response, it would cache that response for a given period of time. A value (set by the administrator of the DNS server handing out the response) called the time to live, or TTL defines that period of time. Once a response goes into cache, the resolver will consult its cached (stored) answer; only when the TTL expires (or when an administrator manually flushes the response from the resolver's memory) will the resolver contact the DNS server for the same information.

Generally, the time to live is specified in the Start of Authority (SOA) record. SOA parameters are:

(Newer versions of named will accept 'M','H','D' & 'W' suffixes indicating that the time interval is respectively in Minutes, Hours, Days and Weeks).

Caching time

A noteworthy consequence of this distributed and caching architecture is that changes to the DNS are not always immediately effective globally. This is best explained with an example: If an administrator has set a TTL of 6 hours for the host www.wikipedia.org, and then changes the IP address to which www.wikipedia.org resolves at 12:01pm, the administrator must consider that a person who cached a response with the old IP Address at 12:00pm will not consult the DNS server again until 6:00pm. The period between 12:01pm and 6:00pm in this example is called caching time, which is best defined as a period of time that begins when you make a change to a DNS record and ends after the maximum amount of time specified by the TTL expires. This essentially leads to an important logistical consideration when making changes to the DNS: not everyone is necessarily seeing the same thing you're seeing. [RFC1537] helps to convey basic rules for how to set the TTL.

Note that the term "propagation", although very widely used, is a poor term to describe the effects of caching. Specifically, it implies that [1] when you make a DNS change, it somehow spreads to all other DNS servers (instead, other DNS servers check in with yours as needed), and [2] that you do not have control over the amount of time the record is cached (you have complete control for all DNS records on your domain, except your NS records and any authoritative DNS servers that use your domain name).

Many people incorrectly refer to a mysterious 48 hour or 72 hour propagation time when you make a DNS change. When you change the NS records for your domain or the IP addresses for hostnames of authoritative DNS servers using your domain (if any), there can be a lengthy period of time before all DNS servers use the new information. This is because those records are handled by the zone parent DNS servers (for example, the .com DNS servers if your domain is example.com), which typically cache those records for 48 hours. However, those DNS changes will be immediately available for any DNS servers that do not have them cached. And, any DNS changes on your domain other than the NS records and authoritative DNS server names can be nearly instantaneous, if you choose for them to be (by lowering the TTL once or twice ahead of time, and waiting until the old TTL expires before making the change).

DNS in the real world

Users generally do not communicate directly with a DNS resolver. Instead DNS resolution is handled transparently via client applications such as web browsers (Internet Explorer, Mozilla Firefox, Safari, Opera, etc), mail clients (Outlook Express, Mozilla Thunderbird, etc), and other Internet applications. When a request is made which necessitates a DNS lookup, such programs send a resolution request to the local DNS resolver in the operating system which in turn handles the communications required.

The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If the cache can provide the answer to the request, the resolver will return the value in the cache to the program that made the request. If the cache does not contain the answer, the resolver will send the request to a designated DNS server or servers. In the case of most home users, the Internet service provider to which the machine connects will usually supply this DNS server: such a user will either configure that server's address manually or allow DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers will generally point to their own nameservers. This name server will then follow the process outlined above in DNS in theory, until it either successfully finds a result, or does not. It then returns its results to the DNS resolver; assuming it has found a result, the resolver duly caches that result for future use, and hands the result back to the software which initiated the request.

Broken resolvers

An additional level of complexity is introduced when resolvers violate the rules of the DNS protocol. Some people have suggested that a number of large ISPs have configured their DNS servers to violate rules (presumably to allow them to run on less-expensive hardware than a fully-compliant resolver), such as disobey TTLs, or indicate a domain name does not exist just because one of its name servers does not respond.

As a final level of complexity, some applications such as Web browsers also have their own DNS cache, in order to reduce use of the DNS resolver library itself, which can add extra difficulty to DNS debugging, as it obscures which data is fresh, or lies in which cache. These caches typically have very short caching times of the order of 1 minute. A notable exception is Internet Explorer; recent versions cache DNS records for 30 minutes.

Other DNS applications

The system outlined above provides a somewhat simplified scenario. The DNS includes several other functions: The DNS uses TCP and UDP on port 53 to serve requests. Almost all DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. TCP typically comes into play only when the response data size exceeds 512 bytes, or for such tasks as zone transfer. Some operating systems such as HP-UX are known to have resolver implementations that use TCP for all queries, even when UDP would suffice.

Extensions to DNS

EDNS is an extension of the DNS protocol which enhances the transport of DNS data in UDP packages, and adds support for expanding the space of request and response codes. It is described in RFC 2671.

Standards

Types of DNS records

Important categories of data stored in the DNS include the following: Other types of records simply provide information (for example, a LOC record gives the physical location of a host), or experimental data (for example, a WKS record gives a list of servers offering some well known service such as HTTP or POP3 for a domain).

Internationalized domain names

Domain names must use only a subset of ASCII characters—the Roman alphabet in upper and lower case, the digits 0 through 9, the dot, and the hyphen. This prevented the representation of names and words of many languages natively. ICANN has approved the Punycode-based IDNA system, which maps Unicode strings into the valid DNS character set, as a workaround to this issue. Some registries have adopted IDNA.

Security issues in DNS

DNS was not originally designed with security in mind, and thus has a number of security issues. DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; DNSSEC modifies DNS to add support for cryptographically signed responses. There are various extensions to support securing zone transfer information as well.

Some domain names can be spoofed by other, similar-looking domain names. E.G., "paypal.com" and "paypa1.com" are different names, yet users may be unable to tell the difference. This problem is much more serious in systems that support internationalized domain names, since many characters that are different (from the point of view of ISO 10646) appear identical on typical computer screens.

Legal users of domains

Registrant

No one in the world really "owns" a domain name except the Network Information Centre (NIC), or domain name registry. Most of the NICs in the world receive an annual fee from a legal user in order for the legal user to utilise the domain name (i.e. a sort of a leasing agreement exists, subject to the registry's terms and conditions). Depending on the various naming convention of the registries, legal users become commonly known as "registrants" or as "domain holders".

ICANN holds a complete list of domain registries in the world. One can find the legal user of a domain name by looking in the WHOIS database held by most domain registries.

For most of the more than 240 country code top-level domains (ccTLDs), the domain registries hold the authoritative WHOIS (Registrant, name servers, expiry dates etc). For instance, DENIC, Germany NIC holds the authoritative WHOIS to a .DE domain name.

However, some domain registries, such as VeriSign, use a registry-registrar model. There are hundreds of Domain Name Registrars that actually perform the domain name registration with the end-user, such as eNom. By using this method of distribution, the registry only has to manage the relationship with the registrar, and the registrar maintains the relationship with the end-users, or 'registrants'. For .COM, .NET domain names, the domain registries, VeriSign holds a basic WHOIS (registrar and name servers etc). One can find the detailed WHOIS (Registrant, name servers, expiry dates etc) at the registrars.

Since about 2001, most gTLD registries (.ORG, .BIZ, .INFO) have adopted a so-called "thick" registry approach, i.e. keeping the authoritative WHOIS with the various registries instead of the registrars.

Administrative contact

A registrant usually designates an administrative contact to manage the domain name. In practice, the administrative contact usually has the most immediate power over a domain. Management functions delegated to the administrative contacts may include (for example):

Technical contact

A technical contact manages the name servers of a domain name. The many functions of a technical contact include:

Billing contact

Self-explanatory, the party whom a NIC invoices.

Name servers

Namely the authoritative name servers that host the domain name zone of a domain name.

Politics

Many investigators have voiced criticism of the methods currently used to control ownership of domains. Critics commonly claim abuse by monopolies or near-monopolies, such as VeriSign, Inc. Particularly noteworthy was the VeriSign Site Finder system which redirected all unregistered .com and .net domains to a VeriSign webpage, this was rapidly removed after widespread critism.

There is also significant disquiet regarding United States political influence over the Internet Corporation for Assigned Names and Numbers (ICANN). This was a significant issue in the attempt to create a .xxx Top-level domain and sparked greater interest in Alternative DNS roots that would be beyond the control of any single country.

Truth in Domain Names Act

In the United States, the "Truth in Domain Names Act", in combination with the PROTECT Act, forbids the use of a misleading domain name with the intention of attracting people into viewing a visual depiction of sexually explicit conduct on the Internet.

See also

References

External links

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: