(Aitchison, 2011) – The Internet Domain Name System
The Internet’s Domain Name System is a specific implementation of the name server concept optimized for the prevailing conditions on the Internet. From our brief history of name servers, we saw that three requisites emerged:
The need for a hierarchy of names
The need to spread the operational loads on our name servers The need to delegate the administration of our name servers The Internet DNS elegantly solves all three problems.
4.2.1 Domains and Delegation
The Domain Name System uses a tree (or hierarchical) name structure. At the top of the tree is the root node, followed by the Top-Level Domains (TLDs), then the Second-Level Domains (SLDs), and then any number of lower levels, each separated with a dot.
_Note The root of the tree is represented most of the time as a silent dot ( . ), which simply means that although
it should be present, it is not always required and can therefore be omitted (silent) simply for convenience. There
are times, however, when this trailing dot is very important.
TLDs are split into two basic types:
Generic Top-Level Domains (gTLDs): For example, .com, .edu, .net, .org, .mil, and so on
Country Code Top-Level Domains (ccTLDs): For example, .us, .ca, .tv, .uk, and so on
Country Code TLDs use a standard two-letter sequence defined by ISO 3166.2 Figure 1–1 illustrates this diagrammatically.
Hình vẽ 5 Domain structure and delegation
What is commonly called a domain name, for instance example.com, is actually a combination of an SLD name and a TLD name and is written from left to right with the lowest level in the hierarchy on the left and the highest level on the right:
sld.tld
The term Second-Level Domain is technically precise in that it defines nodes at the second level within the domain name hierarchy, but is long-winded. To be even more long-winded, there can also be
Third-Level Domains, which are especially relevant with ccTLDS, and so on. By convention—or perhaps laziness—the term domain, or domain name, is generally used to describe a delegated entity, for
instance, example.com, which consists of the SLD example and the TLD com.
Unless precision is required, the term domain name will be used throughout the remainder of this book.
4.2.2 Domain Authority
The concepts of authority and delegation lie at the core of the Domain Name System hierarchy and exactly mirror its hierarchical organization. Each node within the domain name hierarchy is assigned to an authority—an organization or person responsible for the management and operation of that node.
Such an organization or person is said to administer the node authoritatively. The authority for a particular node can in turn delegate authority for lower levels of that node within the domain name hierarchy. The rules and limitations of the authority are covered by agreements that flow through the various nodes in the hierarchy.
The authority for the root domain lies with the Internet Corporation for Assigned Numbers and Names (ICANN—www.icann.org/). Since 1998, ICANN, a nonprofit organization, has assumed this responsibility from the United States Department of Commerce. When ICANN was established, part of its mandate was to open up that part of the domain name hierarchy for which it is responsible to commercial competition. To facilitate this competition, it created the concept of accredited registrars, organizations to which ICANN delegated limited responsibilities for the sale and administration of parts of the domain name hierarchy.
The gTLDs are authoritatively administered by ICANN and delegated to a series of accredited
registrars. The ccTLDs are delegated by ICANN to the individual countries for administration purposes.
Figure 1–1 also shows how any authority may in turn delegate to lower levels in the hierarchy; in other words, it may delegate anything for which it is authoritative. Each layer in the hierarchy may delegate the authoritative control to the next or lower level.
In the case of ccTLDs, countries define their own rules for delegation. Countries like the United States (ccTLD .us), Canada (ccTLD .ca), and others have decided that they will administer both at the national level and delegate to each state (U.S.) or province (Canada) using a two-character
state/province code (for example, .ny = New York, .qc = Quebec, .md = Maryland, and so on). Thus, example.us is the domain name of example that was delegated from the U.S. national ccTLD
administration, and example.md.us is the domain name of example that was delegated from the state of Maryland in the United States.
Other countries, such as the United Kingdom and Brazil, among many others, have opted for
functional segmentation in their delegation models. Thus example.co.uk is the domain name of example registered as a company from the UK registration authority, and example.com.br is the domain name of example registered as a company from the Brazilian registration authority.
Delegation within any domain may be almost limitless and is decided by the delegated authority. For example, many states in the United States and provinces in Canada delegate cities within state/province domains: the domain name example.nb.us would be the town of Example in the state of Nebraska in the United States, and indeed we could have mycompany.example.nb.us, which would be the domain name of mycompany in the town of Example in the state of Nebraska in the United States.
Reading a domain name from right to left will track its delegation.
4.2.3 DNS Implementation and Structure
The Internet’s DNS implementation exactly maps the domain name delegation structure described previously. There are name servers (servers that run DNS software) at each level in the delegated hierarchy, and the responsibility for running the name server lies with the authoritative control at that level. Figure 1–2 shows this diagrammatically.
Figure 1–2. DNS mapped to domain delegation
The root name servers (hereafter called the root-servers) are the most critical resources on the
Internet. When any name server worldwide is queried for information about a domain name for which it does not currently have information, it first asks (queries) one of the root DNS servers. There are currently 13 root-servers worldwide, described in further detail later in this chapter. The root-servers are known to every name server in the world using a special zone file, which is distributed with all DNS software.
The TLD name servers (gTLD and ccTLD) are operated by a variety of organizations, termed Registry Operators, under ICANN agreements and are described more completely later in this chapter.
The owner of a domain name has been delegated the authority for administering the domain name and therefore has the responsibility for the operation of the user (or domain name) name servers—there must be a minimum of two for resilience. The name server operational responsibility may be delegated by the domain owner to an ISP, a web hosting company, or increasingly a domain name registrar. Many companies and domain name owners, however, elect to run their own name servers and even delegate the authority and responsibility for subdomain name servers to separate parts of their organization.
When any name server cannot answer, or resolve, a request for a name, for instance,
fred.example.com, the query is passed to a root-server (discussed in the next section), which returns a referral to the appropriate TLD name server, which in turn provides a referral to the appropriate domain (user) name server which returns the real (authoritative) answer. Figure 1–3 illustrates this process.
Hình vẽ 6: The operational DNS hierarchy
4.2.4 Root DNS Operations
The root-servers (root DNS) are the responsibility of ICANN, but are operated under an agreement known as the Cooperative Research and Development Agreement (CRADA) that was signed between ICANN and the U.S Department of Commerce (www.icann.org/committees/dns-root/crada.htm). This agreement covers the methods and processes by which updates to the root name systems are carried out. ICANN also created the Root Server System Advisory Committee (RSSAC) to provide advice and guidance as to the operation and development of this critical resource. The IETF was requested by the RSSAC to develop the engineering standards for operation of the root-servers. This request resulted in the publication of RFC 2870.
There are currently 13 root-servers. They occupy a reserved domain name: root-servers.net. Each root-server typically comprises many physical servers but, using a process called anycasting, each physical server (called a root-server instance in the jargon) shares a single IP address. Root-servers are named from a.root-servers.net through m.root-servers.net, as shown in Table 1–1. As of 2010, while there are 13 named root-servers, there are just over 200 instances throughout the world. Current
information about the root-servers can be obtained from www.root-servers.org.
The job of the root-servers is to provide a referral to the authoritative name servers for the required TLDs (gTLDs or ccTLDs). For example, if a user requests information about fred.example.com, then the root-servers will supply a list of the authoritative name servers for the .com TLD. In 2004, ICANN took over responsibility for the maintenance of the root-servers TLD master file—the file that lists the authoritative servers for each TLD. Distribution of this file to each of the operational root-servers is carried out using secure transactions. To further increase security, the server providing the root updates is accessible only from the operational root-servers. It is not a publicly visible server. Figure 1–4
illustrates this process.
4.2.5 Top-Level Domains
As was mentioned earlier in this chapter, Top-Level Domains are split into Generic Top-Level Domains and Country Code Top-Level Domains. Each group is administered slightly differently, but all are controlled by ICANN. ICANN controls the gTLDs by a purely contractual process. In the case of ccTLDs, because multiple countries and national sovereignty issues are involved, the process is essentially
consultative rather than purely contractual.
Generic Top-Level Domains
Generic Top-Level Domains, or gTLDs, are controlled by ICANN using a contractual process. ICANN inherited the gTLDs listed in Table 1–2 on its establishment in 1998.
In November 2000, ICANN authorized the new gTLDs you see in Table 1–3.
As can be seen in the list in Table 1–3, some of the gTLDs, such as .aero, have limited registration policies; others do not. During 2004, ICANN undertook a review of gTLD policy, one of the effects of which was to create a new gTLD subset called Sponsored TLDs (sTLDs) to clarify the form of registration access to be offered by new gTLDs. The domains .museum, .coop, .aero, .gov, .mil, .edu, and .int are all now classified as sTLDs. Since November 2000, ICANN has authorized six new TLDs, all sTLDs: .travel, .jobs, .mobi, .cat, .tel, and .asia.
Authorizing new gTLDs has always attracted controversy. In June 2008, ICANN adopted a new gTLD policy based on a report by its Generic Names Supporting Organization (GNSO) Working Group. In essence, this policy places no limits on the number of new gTLDs that can be created in the future and allows any competent party to propose a new gTLD that will be judged against an objective set of
criteria. As of the date of writing, no gTLD application has been authorized under the new policy.
Country Code Top-Level Domains
Country Code Top-Level Domains are controlled by ICANN and consist of a two-character code defined by ISO 3166. ICANN has neatly sidestepped the thorny issue of what is a country by the use of ISO 3166. ISO 3166 is controlled by a branch of the United Nations, which is pretty experienced in the matter of defining what is (and what is not) a country!
ccTLDs are delegated by ICANN to a country code manager. Country code manager is a historic term reflecting a time when the Internet was a small and intimate place—more often today the country code manager is a branch of government, and the country code has become a valuable economic resource.
The relationship between ICANN and country code managers is complicated by sovereignty and cultural sensitivity, and the process is largely consultative rather than contractual. It is a testament to the good will of all parties that the process works as well as it does. In general, country managers are
responsible for administering and operating their delegated country codes and the associated TLD servers with regard to their local circumstances and within the spirit of RFC 1591 and ICANN’s ICP-1 (www.icann.org/en/icp/icp-1.htm). As part of the move to make the Internet more accessible worldwide, Internationalized Domain Name (IDN) ccTLDs are being introduced. See Chapter 17 for IDN details and Appendix A for more information on IDN ccTLDs.
The country delegation models are typically based on a federated model; for example, by state or province—example.md.us—or a functional model, for example, example.co.uk or example.com.br.
However, many exceptions do exist, reflecting local conditions and needs. The most famous that spring to mind are .tv (Tuvala) and .la (Laos), whereby those countries have sought to optimize the economic value of the domain name resource.
The Internet Assigned Numbers Authority (IANA) maintains a current list of country code managers at www.iana.org/domains/root/db/ on behalf of ICANN.