Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

DNS Name Space, Architecture and Terminology

The name space is the most fundamental part of any name system, since it is what defines

the ways that the names themselves are created. The name space tells us what form

names may take, and provides the rules for how they are created. Most importantly, it

specifies the architecture of the names—the internal structure of names themselves. This in

turn has a critical influence on how name registration and resolution work, making an

examination of name space and architecture issues the obvious place to start in learning

the details of DNS.

In this section I describe the concepts behind the DNS name space and its structure. I begin

with an overview of the DNS name space and description of the hierarchical architecture it

uses. I then provide more detail on the name structure, and also explain the terminology

often used to refer to parts of the name space. I provide a formal description of DNS labels

and the official and unofficial rules for creating domain names. I conclude with a description

of domain name specifications, and explain the concept of “qualification” and how fully-

qualified and partially-qualified names differ.

DNS Domains and the DNS Hierarchical Name Architecture

The most important element of a name system's name space is its name architecture,

which describes how names are constructed and interpreted. The architecture of the

Domain Name System is, unsurprisingly, based on the concept of an abstraction called a

domain. This is obviously a good place to start in explaining how DNS works. Unfortunately,

it's not the easiest concept to explain from scratch, so as usual, I'll do my best and ask for

your patience. ☺

The Essential Concept in the DNS Name Space: Domains

Dictionary definitions of the word “domain” generally convey the notion of a sphere of

influence, or area of control or rulership. An essential concept is that in many different

contexts, control or authority can be exerted at many different levels. One sphere of

influence may contain smaller ones, which can in turn contain smaller ones still. This means

that such domains are naturally arranged in a hierarchy.

An obvious example would be geopolitical domains. We have no centralized “world

government” on earth, but we do have the United Nations, which deals with world-wide

issues. At the next level down, we have individual countries. Some of these countries have

divisions such as states and provinces. Still lower levels have counties, municipalities,

neighborhoods and individual residences or businesses. The “domains” are inherently

hierarchical in organization.

The Domain Name System uses the word domain in a manner very similar to this, and

employs a hierarchical structure that works in much the same way as the geopolitical

example. In DNS, a domain is defined as either a single object or a set of objects that have

been collected together based on some type of commonality. Usually in DNS that common-

ality is that they are all administered by the same organization or authority, which makes the

name hierarchy tightly linked to the notion of the DNS hierarchical authority structure.

Note: The term “domain” is also used in other contexts in the world of networking.

The most notable example of this is the use of the term in Microsoft networking,

where it too is used to represent the notion of a collection of objects under

common authority. However, the two types of domain are completely different and not

related beyond this conceptual level.

The DNS Hierarchical Tree Structure of Names

One could construct a tree diagram with the United Nations on top with lines pointing to

each of the countries on earth. Then, within the United States, for example, we could draw

lines to each of the states; within each state, lines to each county and so on. The result

would be something that looks like an upside-down tree, as we can see in Figure 235. This

is called a tree structure.

Trees are used all over computing and networking; for example, trees are a type of LAN

topology. For our purposes in explaining DNS, the best example of a tree structure is the

directory tree used to store files on a computer's hard disk or other storage devices. The

root directory is at the top of the structure and may contain named files and/or named direc-

tories. Each directory can itself contain individual files or subdirectories, which can in turn

contain their own subdirectories, and so on.

The domain name structure in DNS is conceptually arranged in exactly the same way, only

instead of dealing with files, DNS deals with named objects, usually devices like IP hosts.

The highest level is still the root of the tree. It contains a number of domains, each of which

Figure 235: Example of a Global Hierarchical Domain Architecture

This diagram shows an example of hierarchical architecture, based on political divisions. The United Nations

is an umbrella organization representing (to one extent or another) all of the world’s nations. It is the root of

the tree; underneath it we find individual nations. Each nation then is further subdivided in a manner it

chooses; for example, Canada has provinces and territories, and the USA individual states. These can in turn

be further subdivided in any number of ways.

United Nations

ZimbabweAustralia Canada South Korea USAPortugalBrazil

...

Alabam a

Afghanistan

AlaskaAlberta

British

Columbia

Yuk on

Territory

...

Wyom ing

...

can contain individual objects (names) and/or lower-level domains. Lower-level domains

can in turn have still lower-level domains, allowing the tree as a whole to take on an

arbitrary structure.

The Benefits of the DNS Hierarchical Name Architecture

Like a directory structure, the DNS hierarchical name architecture allows names to be

organized from most general to most specific. It also has complete flexibility, allowing us to

arrange the structure in any way that we want. For example, we could make a name system

that is structured exactly paralleling the geopolitical organization chart I described earlier.

We could have the root of the name structure represent the “United Nations”, and create a

domain for each country. Then for those countries that have states, like the United States,

we could create “state domains” within those countries. Smaller countries not needing

those domains could have “city domains” directly under the country domain. The hierarchy

is flexible, because at each level it can be given a suitable substructure.

Key Concept: The DNS name space is arranged into a hierarchy of domains

shaped like an inverted tree. It is structurally similar to the directory structure of a file

system, with a root that contains domains, each of which can contain subdomains

and so forth.

It's important to remember that every standalone internetwork can have its own name

space and unique hierarchical structure. Many times, people conflate the idea of “a DNS

name space” with “the DNS name space”. The latter refers to the DNS hierarchy used for

the global Internet, and it's obvious that this deserves a great deal of attention. But it is just

one possible arrangement, if an important one, of an infinite number of possible structures.

In the remaining topics of this section, I continue the generic descriptions of DNS name

space and architecture, including a look in the next topic at DNS names and terminology.

The section on name registration and authorities provides more specific information on the

Internet's DNS hierarchy. As we'll see there, geopolitical structures are in fact used in a

manner similar to what I described above to assign names to some of the Internet's

computers, but other parts of the hierarchy are different.

DNS Structural Elements and Terminology: Domains, Subdomains, and

Nodes; Roots, Leaves and Branches; Parents, Children and Siblings

Now that we understand the fundamentals of the Domain Name System's name space, let's

look at the DNS structure in more detail. At the same time, we can get a better handle on

the many different terms used to refer to parts of the DNS domain name hierarchy.

DNS Tree-Related Terminology

We saw in the previous topic that the DNS name structure is shaped somewhat like a tree;

the comparison between structured elements and trees is a common one in networking.

The main difference between technology and biology here is that DNS trees grow from the

top down, instead of reaching for the sky. The analogy to a tree naturally leads to the use of

several tree-related terms in describing the DNS name structure, some of which are illus-

trated in Figure 236:

☯ Root: This is the conceptual top of the DNS name structure. The root domain in DNS

contains the entire structure. By definition, it has no name; it is null.

☯ Branch: A branch is any contiguous portion of DNS hierarchy. It consists of a domain

and all the domains and objects within it. All branches connect together to the root, just

like in a real tree. (Yes, it would be better if the root were called the trunk, but computer

science majors apparently don't take botany as electives. ☺)

☯ Leaf: This is an “end object” in the structure, that is, a domain that doesn't have

anything underneath it. Again, the analogy to a leaf being at the end of a sequence of

branches is apt.

There is no specific term to refer to a domain that is not a leaf. These are sometimes called

interior nodes, meaning that they are in the middle of the structure. A node is the generic

computing term for an object in a topology or structure; it is used throughout this Guide. So,

in DNS, every node is a domain, and may be either an interior node that contains additional

domains and/or objects, or a leaf that is a specific named device. The term domain is thus

somewhat ambiguous, as it can refer to either a collection of objects which represents a

branch of the tree, or a specific leaf.

DNS Domain-Related Terminology

There are also several “domain-like” terms that are often used to refer to domains at

different levels of the hierarchy. These terms, shown in Figure 236, include:

☯ Root Domain: This is the root of the tree, as before.

☯ Top-Level Domains (TLDs): These are the highest-level domains directly under the

root of the tree. They are also sometimes called first-level domains.

☯ Second-Level Domains: Shockingly enough, these are the domains located directly

below the top-level domains.

☯ Subdomains: In some contexts, this term refers only to domains that are located

directly below the second-level domains (but see below).

Key Concept: The top of the DNS name space is the root; under the root come top-

level domains, and within these are second-level domains and then subdomains. In

theory, any number of levels of subdomains can be created. A branch is any

contiguous portion of the DNS tree; a leaf is a domain with nothing underneath it in the

structure, and usually represents a single device.

The term “subdomain” can also be used generically, like the word “domain” itself. In that

case, it refers simply to the relationship between two domains, with a subdomain being

under another domain in the structure. This means, for example, that top-level domains can

be said to be subdomains of the root; every second-level domain is a subdomain of a top-

level domain, and so on. But again, sometimes “subdomain” means specifically a third-level

or lower domain.

DNS Family-Related Terminology

Another set of terminology you will run into compares the DNS tree structure not to a living

tree, but in fact, to another analogy: a family tree. These terms are most often used to

describe how a particular domain under discussion relates to the other domains or subdo-

mains around it, so they are relative terms. The ones usually seen are (see Figure 237):

Figure 236: DNS Name Space Tree and Domain-Related Terminology

The top of the DNS name space is the root of the tree, and has no name. Under the root comes any number

of top-level domains (TLDs); within each of these can be placed second-level domains, then within those

subdomains, and so forth.

Some of the “tree” terminology used in DNS is also shown here. The portion of the tree with the purple

background is one branch; the blue area highlights a smaller “sub-branch” within that branch. The green

nodes within that blue area are the leaves of that smaller branch of the tree.

Root

Top-Level

Domain (TLD)

...

2nd-Level

Domain

Top-Level

Domain (TLD)

Top-Level

Domain (TLD)

Top-Level

Domain (TLD)

2nd-Level

Domain

2nd-Level

Domain

2nd-Level

Domain

Subdomain Subdomain Subdomain Subdomain

Sub-

domain

Sub-

domain

Sub-

domain

...

Sub-

domain

...

☯ Parent Domain: The domain that is above this one in the hierarchy. For example, the

root domain is the parent of all top-level domains.

☯ Child: A domain at the next level down from this one in the hierarchy. Thus, the top-

level domains are children of the root.

☯ Sibling: A peer at the same level as this one in the hierarchy, with the same parent.

Thus, all top-level domains are siblings with the root as a parent; all second-level

domains within a particular TLD are siblings and so on.

Key Concept: The domain above a given domain in the DNS name space is called

its parent domain; domains at the same level within the same parent are siblings;

and subdomains are called children of that domain.

Figure 237: DNS Name Space “Family Tree”

This diagram is similar to Figure 236, but I have labeled the nodes differently to show the “family-oriented”

terminology sometimes used in DNS. In this case, the names are relative to the interior node shown in cyan.

The domain immediately above it is its parent node; other nodes on the same level are siblings, and subdo-

mains within it are children of that node.

Root

Top-Level

Domain (TLD)

...

Sibling

Domain

Top-Level

Domain (TLD)

Parent

Domain

Top-Level

Domain (TLD)

Interior

Node

Sibling

Domain

Sibling

Domain

Child

Subdomain

Child

Subdomain

Child

Subdomain

Child

Subdomain

...

Grandchild

Subdomain

Grandchild

Subdomain

Grandchild

Subdomain

Grandchild

Subdomain

Restrictions on DNS Tree Structure

Note that like a real tree, the DNS name structure must be a true tree in its structure. Every

domain can have only one parent (except the root), just as every branch of a tree connects

to only one limb (except the root/trunk). Also, no “loops” can appear in the structure; you

can't have a domain whose child is also its parent, for example.

Key Concept: A DNS name space must be arranged as a true topological tree. This

means each domain can have only one parent, and no “loops” are permitted in the

structure.

I also want to point out that even though the name hierarchy represents an arrangement of

named devices, it is only a logical structure. There is no necessary correspondence to the

physical location of devices. A domain with ten children may represent 11 devices in 11

different countries. We'll explore this more when we look at DNS authority structures.

DNS Labels, Names and Syntax Rules

We've seen how the DNS name space hierarchy allows us to arrange domains into a virtual

tree that reflects the characteristics of how the devices themselves are organized. While

using a hierarchical name space is inherently more complex than a flat name space, it

yields a powerful result: the ability to specify names that can be locally managed while

remaining globally unique. At the same time, the complexity of the tree yields the benefit of

relatively simple name construction using domain identifiers.

DNS Labels and Label Syntax Rules

Naming in DNS begins with giving each domain, or node, in the DNS name space a text

label. The label identifies the domain within the structure, and must follow these syntax

rules:

☯ Length: Each label can theoretically be from 0 to 63 characters in length. In practice, a

length of 1 to about 20 characters is most common, with a special exception for the

label assigned to the root of the tree (see below).

☯ Symbols: Letters, numbers are allowed, as well as the dash symbol (“-”). No other

punctuation is permitted, including the underscore (“_”).

☯ Case: Labels are not case-sensitive. This means that “Jabberwocky” and “jabber-

wocky” are both permissible domain name labels, but they are equivalent.

DNS Label Uniqueness Requirement

Every label must be unique within its parent domain. So, for example, if we have a top-

level domain (TLD) called “rocks”, we can only have one subdomain within “rocks” called

“crystal”. Due to the case insensitivity of labels, we cannot have both “CRYSTAL” and

“crystal” within “rocks”, because they are considered the same.

It is this concept of “local uniqueness” within a parent domain that ensures the uniqueness

of names as a whole, while allowing local control over naming. Whoever is in charge of the

“rocks” domain can assign names to as many individual objects or subdomains as he likes

as long as they are unique within the domain. Someone else, say, the maintainer of the

“glass” domain, can also create a subdomain called “crystal” within “glass”; there is no

conflict because the “glass” and “rocks” domains are separate. Of course, since all top-level

domains have the same parent (the root), all TLDs must be unique.

Key Concept: Each node in the DNS name space is identified by a label. Each label

must be unique within a parent domain, but need not be unique across domains.

This enables each domain to have local control over the names of subdomains

without causing any conflict in the full domain names created on a global level.

Constructing Domain Names From Domain Labels

Each individual domain within the domain name structure can be uniquely identified using

the sequence of labels that starts from the root of the tree and progresses down to that

domain. The labels at each level in the hierarchy are listed in sequence, starting with the

highest level, from right to left, separated by dots. The result is the formal definition of a

domain name.

The root of the name space is given a zero-length, “null” name by default. That is, the label

for the root exists, it's just empty. This little bit of geekery is done because the root techni-

cally is part of every domain name. This means it must be included in every domain name.

If it were something long like “root”, we would have to include that at the end of every

domain name. This would simply make every name longer, while not really adding any

useful information—we already know every domain name is under the root.

Let's take the example above again, of a top-level domain called “rocks”, within which is a

second-level domain “crystal”. The domain name of “rocks” is “rocks.”, with the dot

separating “rocks” and “” (the null root). In practice, the trailing dot is often omitted, so the

domain name of the TLD “rocks” can be considered to be just “rocks”. The subdomain

“crystal” within “rocks” has the domain name “crystal.rocks”. If we had a named device

called “salt” within the “crystal.rocks” domain, it would be called “salt.crystal.rocks”. This is

pretty straight-forward, as you can see in the very simple Figure 238.

We can use these names to easily identify subdomains of a particular domain. For example,

if we start with “salt.crystal.rocks”, it's obvious that “crystal.rocks” is its parent domain. It's

also clear that both “crystal.rocks” and “salt.crystal.rocks” are subdomains of “rocks”; one is

a single level down from “rocks” and the other is two levels down.

DNS Name Length Limit

There is a maximum limit of 255 characters for a complete domain name, for implemen-

tation purposes. In practice, most domain names are much shorter than this limit, as it

would violate the whole purpose of domain names if we let them get so long that nobody

could remember them anyway.

Resource Specification

In many protocols, it is possible to specify a particular resource within a domain name by

providing a directory structure after a name. This is done using the standard TCP/IP uniform

resource locator (URL) syntax, where a path is indicated using slashes to separate subdi-

rectories. For example, a specific file at “salt.crystal.rocks” might be located at

“salt.crystal.rocks/chem/composition”.

While DNS names are case-insensitive, the labels in a URL path are not. So this example

would be different from “salt.crystal.rocks/chem/Composition”. See the topic on URL syntax

for more details.

Figure 238: DNS Labels and Domain Name Construction

Each node in the DNS name space has a label (except the root, whose label is null). The domain name for a

node is constructed simply by placing in order the sequence of labels from the top of the tree down to the

individual domain, going from right to left, separating each label with a dot (period).

Root

rocks

crystal

salt

rocks

crystal.rocks

salt.crystal.rocks

Key Concept: A domain name is a string of text that uniquely identifies a particular

node in the name space. The domain name for a node is constructed by concate-

nating in right-to-left order all the labels in the branch of the DNS tree starting from

the top of the tree down to the particular node, separating each by a dot (period.)

Absolute (Fully-Qualified) and Relative (Partially-Qualified) Domain Name

Specifications

The previous topic showed how we can specify the domain name of any node in the DNS

name hierarchy. We simply start at the root node and follow the sequence of subdomains

down to the node in question, listing each level's labels separated by a dot. When we do

this, we get single name that uniquely identifies a particular device.

Fully-Qualified Domain Names (FQDNs)

Technically, if a top-level domain “A” contains a subdomain “B” that in turn contains

subdomain “C”, the full domain name for “C” is “C.B.A.”. This is called the fully-qualified

domain name (FQDN) for the node. Here, the word “qualified” is synonymous with

“specified”. The domain name “C.B.A.” is fully-qualified because it gives the full location of

the specific domain that bears its name within the whole DNS name space.

Fully-qualified domain names are also sometimes called absolute domain names. This term

reflects the fact that one can refer unambiguously to the name of any device using its FQDN

from any other portion of the name space. Using the FQDN always instructs the person or

software interpreting the name to start at the root and then follow the sequence of domain

labels from right to left, going top to bottom within the tree.

Partially-Qualified Domain Names (PQDNs)

There are also some situations in which we may refer to a device using an incomplete

name specification. This is called a partially-qualified domain name (PQDN), which means

that the name only partially specifies the location of the device. By definition, a PQDN is

ambiguous, because it doesn't give the full path to the domain. Thus, one can only use a

PQDN within the context of a particular parent domain, whose absolute domain name is

known. We can then find the FQDN of a partially-specified domain name by appending the

partial name to the absolute name of the parent domain. For example, if we have the PQDN

“Z” within the context of the FQDN “Y.X.”, we know the FQDN for “Z” is “Z.Y.X.”

Why bother with this? The answer is convenience. An administrator for a domain can use

relative names as a short-hand to refer to devices or subdomains without having to repeat

the entire full name. For example, suppose you are in charge of the computer science

department at the University of Widgetopia. The domain name for the department as a

whole is “cs.widgetopia.edu.” and the individual hosts you manage are named after fruit.