Let us now look at how domains and zones are related.
At the beginning of this tutorial series, we discussed domains and how DNS is used to resolve domain names to IP addresses. Let us now take a closer look at the domain’s structure.
DNS Name Space
The Domain Name System (DNS) is a hierarchical and distributed naming system. A tree data structure is used to represent the domain name space.
A namespace is a context in which all object names must be unambiguously resolvable. The internet, for example, is a single DNS name space in which all network devices with a DNS name can be resolved to a specific address (for example, www.microsoft.com resolves to 188.8.131.52).
A namespace can be hierarchical or flat. A flat namespace does not scale, well, because it can only expand so far before all available names are exhausted. When a name is used more than once in a namespace, the namespace violates the requirement of being unambiguously resolvable.
A hierarchical namespace is divided into areas known as sub-namespaces. Within the overall namespace, each area has its own sub-namespace.As a consequence, in order to have an unambiguously resolvable name within the namespace hierarchy, each object must have a unique name only within its sub-namespace. As a direct consequence, hierarchical namespaces can scale to extremely large networks—as more objects are added to the overall name space, you must find unique names for them within only the sub-namespace to which they belong. That is why your host machine can be called www along with millions other hosts.
DNS namespaces are all hierarchical. Domains are the sub-namespaces in the DNS hierarchical namespace. A relatively distinguished name is the unique name of a computer within a domain.
Because a fully-qualified domain name (FQDN) can be fully resolved to a unique object within the entire DNS hierarchy, computers with the same relative distinguished name can exist in different sub-namespaces (domains) of the namespace hierarchy.
You could, for example, have server1 in the widgets.yourdomain.com domain (the widgets.yourdomain.com namespace) and server1 in the gadgets.widgets.yourdomain.com namespace. They can be resolved to different FQDNs because they are in different sub-namespaces in the hierarchical namespace—server1.widgets.yourdomain.com and server1.gadgets.widgets.yourdomain.com.
Don’t be concerned if it doesn’t make sense to you. It will become clear to you in a few minutes.
The DNS can be thought of as an upside down tree.
DNS domains, like the UNIX file system, are organized as a series of descending branches, similar to tree roots. Each branch represents a domain, and each sub branch represents a subdomain. Domain and subdomain are relative terms. A given domain is a subdomain in the hierarchy to the domains above it and a parent domain to the subdomains below it.
In the above figure, for example, .edu is a parent domain to the nsu, and mit domains. Alternatively, you could say that those are subdomains of the .com domain.
In the below figure, .com is a parent domain to the acme, apex and buss domains. Alternatively, you could say that those are subdomains of the .com domain. The acme domain, in turn, is the parent of three subdomains (boss, toys, and sec).
Each node in the tree has a text label (without dots) of up to 63 characters. The root is given a null (zero-length) label. The full domain name of any node in the tree is the label sequence from that node to the root. Domain names are always read from the node to the root (“up” the tree), with dots separating the names.
If the root node’s label actually appears in a node’s domain name, the name looks as though it ends in a dot, as in “www.google.com.” . (It actually ends with a dot – the separator – and the null label for the root). When the label of the root node appears alone, it is written as a single dot, “.”, for convenience. As a consequence, some software interprets a trailing dot in a domain name to indicate that it is absolute. An absolute domain name is written relative to the root and specifies a node’s position in the hierarchy unambiguously. A fully qualified domain name, or FQDN, is another term for an absolute domain name.
Names that lack trailing dots are sometimes interpreted as relative to a domain other than the root, just as directory names that lack a leading slash are frequently interpreted as relative to the current directory.
DNS requires sibling nodes or nodes that are children of the same parent, to have distinct labels. This constraint ensures that a domain name only identifies a single node in the tree. The restriction isn’t really a restriction because the labels only have to be unique among the children, not among all the nodes in the tree.
The same rule applies to the UNIX filesystem: two sibling directories cannot have the same name. You can’t have two /usr/bin directories in the same namespace, just like you can’t have two hobbes.pa.ca.us nodes ( figure below). However, you can have both a hobbes.pa.ca.us and a hobbes.lg.ca.us node, just as you can have a /bin directory and a /usr/bin directory.
Domains And Domain Names
People frequently mix up domain names and domains. Though they are frequently confused, they are technically two distinct concepts. A domain is merely a branch(subtree) of the domain name space. A domain’s domain name is the same as the domain name of the node at the domain’s very top. As shown in Figure 2.3, the top of the purdue.edu domain is a node named purdue.edu.
Any domain name in the subtree is considered a part of the domain. A domain name can be in many domains because it can be in many subtrees. As shown in Figure 2.5, the domain name pa.ca.us is part of the ca.us domain as well as the us domain.
In essence, a domain is a subtree of the domain name space. And the domain name is the name of the top node of the subtree.
But where are all the hosts if a domain is simply made up of domain names and other domains? Domains are just groups of hosts, aren’t they?
The hosts, as represented by domain names, are present. Keep in mind that domain names are simply indexes in the DNS database. “Hosts” are domain names that point to information about specific hosts. And a domain includes all of the hosts whose domain names are contained within the domain. The hosts are linked logically, usually by geography or organizational affiliation, rather than by network, address, or hardware type. You could have ten different hosts, each on a different network and possibly even in a different country, but all in the same domain. This is how google can have hundreds of thousands of different hosts all in the same domain(google.com).
Individual hosts are generally represented by domain names at the tree’s leaves, which may point to network addresses, hardware information, and mail routing information. Domain names in the tree’s interior can both name hosts and point to domain information. Interior domain names do not have to be one or the other. They can represent both the domain to which they belong and a specific host on the network. For example, google.com is the domain name of Google as well as the domain name of a host that hosts Google’s primary web server.
The above diagram depicts an interior node with both host and structural data. Let us go over this again. A domain can have multiple subtrees, known as subdomains. In DNS documentation, the terms domain and subdomain are frequently used interchangeably or nearly so. Subdomain is only used as a relative term in this context: a domain is a subdomain of another domain if the root of the subdomain is within the domain.
Comparing their domain names is a simple way to determine whether one domain is a subdomain of another. The domain name of a subdomain is followed by the domain name of its parent domain. For example, because shop.mycompany.com ends with mycompany.com, it must be a subdomain of mycompany.com. Similarly, mycompany.com is a subdomain of com.
Domains are frequently referred to by level, in addition to being referred to in relative terms as subdomains of other domains. The terms top-level domain and second-level domain may be heard on mailing lists and in Usenet newsgroups. These terms simply refer to the position of a domain in the domain name space:
A top-level domain is a child of the root.
A first-level domain is a child of the root (i.e., a top-level domain).
A second-level domain is a child of a first-level domain, and so on.
Is the difference between a domain and a domain name now clear to you?
If not, please allow us to elaborate. Recognizing the distinction is advantageous to you.
A network domain is an administrative grouping of multiple private computer networks or local hosts that are all part of the same infrastructure. An example might help you understand.
As you can see, Hogwarts has several towers. We designed and built networks in all of the towers. Because there are so many users in the Slytherin Dungeon, we’ve set up two networks, say, network A and network B.
Half of the Slytherin students use Network A, 192.168.10.0/24. The VLAN identifier for this network is VLAN 10. The other half of Slytherin students connect to Network B, 192.168.20.0/24. VLAN 20 is the VLAN identifier for this network. Do not be concerned about the VLAN identifier.
The dark tower now has its own network as well. Dark Tower’s entire staff connects to Network C, 192.168.0.0/24. VLAN 11 is the VLAN identifier for this.
The router Router1 acts as the gateway for all three networks, and the entire infrastructure is physically connected via ethernet. Networks B and C are connected via Router1 and have full access to one another.
Network A is completely separate from the other two and has no access to them. As a direct consequence, Networks B and C are in the same network domain, whereas Network A is in its own network domain, albeit alone.
Let us now talk about the domain name. A domain name is used to identify a domain. What are you going to call domains A and B? A is a distinct domain from B. B is made up of two distinct networks. You can call them anything. You can call Domain A ‘voodoo’ and Domain B ‘blah’. It’s completely up to you.
A domain name is a string of characters that identifies a domain’s administrative autonomy, authority, or control on the Internet. Domain names are frequently used to identify Internet-based services such as websites, email services, and so on. In 2017, 330.6 million domain names were registered. Domain names are used in a variety of networking contexts as well as for application-specific naming and addressing. A domain name, in general, identifies a network domain or an Internet Protocol (IP) resource, such as a personal computer or a server computer.
The distinction between domain and domain name is analogous to the distinction between a street name and the actual street. It’s a thing with a name. It’s a digital thing in the case of a domain…
Or the distinction between you and your name. A car and its manufacturer. One is a thing, and the other is its name.
What about the DNS? What is the function of DNS?
Within the Domain Name System, domains that must be accessible from the public Internet can be assigned a globally unique name (DNS).
Domain names are formed by the Domain Name System’s rules and procedures for networks that are publicly accessible. Any name registered in the DNS is a domain name. Domain names are organized into subordinate levels (subdomains) of the nameless DNS root domain. The top-level domains (TLDs), which include the popular domains com, info, net, edu, and org, and the country code top-level domains, are the first-level set of domain names (ccTLDs). The second-level and third-level domain names in the DNS hierarchy are typically open for reservation by end-users who wish to connect local area networks to the Internet, create other publicly accessible Internet resources, or run web sites.
A second- or third-level domain name is typically registered by a domain name registrar, who sells its services to the general public.
A fully qualified domain name (FQDN) is a domain name that is fully specified with all labels in the DNS hierarchy, with no parts left out. A FQDN is traditionally terminated with a dot (.) to denote the top of the DNS tree. Labels in the Domain Name System are case-insensitive and can thus be written in any desired capitalization method, but in technical contexts, domain names are typically written in lowercase.
Remember our dig command output?
; <<>> DiG 9.16.35 <<>> ns.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24785
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: bb7d6c724eb39b63ebcfb71f63b0580020c97b5fc3b155da (good)
;; QUESTION SECTION:
;ns.google.com. IN A
;; ANSWER SECTION:
ns.google.com. 0 IN A 184.108.40.206
;; Query time: 145 msec
;; SERVER: 172.31.6.10#53(172.31.6.10)
;; WHEN: Sat Dec 31 21:40:49 Bangladesh Standard Time 2022
;; MSG SIZE rcvd: 86
It is now time to explain what the output actually means and how you can use this information.
The Domain Name System defines a database of network resource information elements. The information elements are classified and organized using a list of DNS record types and resource records (RRs).
Resource records, or RRs, contain information about domain names. Records are classified into classes, each of which corresponds to a specific type of network or software. There are currently classes for internet (any TCP/IP-based internet), Chaosnet-based networks, and Hesiod-based networks. (Chaosnet is an ancient network with mostly historical significance).
Each record has a type (name and number), an expiration time (time to live), a class, and data that is unique to that type. A resource record set (RRset) is a collection of resource records of the same type that have no special ordering. When queried, DNS resolvers return the entire set, but servers may use round-robin ordering to achieve load balancing. Domain Name System Security Extensions (DNSSEC), on the other hand, work on the entire set of resource records in canonical order.
All records sent over an Internet Protocol network use the common format specified in RFC 1035.
By far the most popular is the internet class. (We’re not sure if anyone still uses the Chaosnet class, and the Hesiod class is mostly used at MIT). The internet class is the focus of this tutorial.
Within a class, records can be of various types, which correspond to the various types of data that can be stored in the domain name space. Different classes define different record types, though some are shared by multiple classes. Almost every class, for example, defines an address type. Each record type in a given class defines a specific record syntax that must be followed by all resource records of that class and type.
Don’t be concerned if this information appears shady. It will become clear in no time.
So far, we’ve discussed the theoretical structure of the domain name space, what kind of data it stores, and even hinted at the types of names you might find in it with our (sometimes fictitious) examples. However, this will not assist you in decoding the domain names you encounter on a daily basis on the Internet.
The Domain Name System does not impose many rules on domain name labels and does not assign any particular meaning to the labels at any level. You can choose your own semantics for your domain names when you manage a part of the domain name space. Nobody would object if you named your subdomains A through Z (though they might strongly recommend against it).
The existing Internet domain name space, on the other hand, has some self-imposed structure. Domain names, particularly in the upper-level domains, adhere to certain conventions (not rules, really, as they can be and have been broken). These customs keep domain names from appearing completely random. Understanding these traditions is extremely useful when attempting to decipher a domain name.
You’ll probably find it much easier to understand most domain names now that you know what most top-level domains represent and how their namespaces are structured. Let’s practice dissecting a few:
You’ve already gotten a head start on this one because we’ve already told you that google.com is the domain of Google. Google employees are in charge of managing this domain. (If you didn’t already know, you could have deduced that the name belongs to a commercial organization because it’s in the top-level com domain). Google.com’s corporate section’s subdomain is corporate. Finally, lithium is the name of a specific host in the domain – one of about a hundred or so, if they have one for each element.
This example is a little more difficult, but not by much. The hp.com domain is almost certainly owned by the Hewlett-Packard Company (in fact, we mentioned this earlier, too). Their corporate headquarters is undoubtedly their corp subdomain. And Winnie is probably just a silly name that someone made up for a host.
You’ll need to apply your knowledge of the US domain here. ca.us is obviously the domain of California, but mpk is anyone’s guess. Unless you know your San Francisco Bay Area geography, it would be difficult to tell that this is Menlo Park’s domain. (And no, this is not the same Menlo Park where Edison lived; that is in New Jersey.)
We’ve included this example to avoid the misconception that all domain names have four labels. gryffindortower is a subdomain of hogwarts.com. commonroom is gryffindor’s site. And daphne is a host in the commonroom.
We hope that all of your questions about domains, domain names, and DNS have been answered. Let’s talk about zones and zone files now.
Zones have already been discussed in an earlier section. We discussed zones and how they help us. Let’s talk about zones some more. To fully comprehend the concept and significance of zones, you must first comprehend delegation.
What is DNS Zone Delegation?
Remember how one of the primary goals of the Domain Name System design was to decentralize administration? Delegation is used to accomplish this. Domain delegation is similar to task delegation at work. A manager may divide a large project into smaller tasks and assign responsibility for each to different employees.
Similarly, an organization that manages a domain can subdivide it. Each of these subdomains can be delegated to a different organization. This means that an organization is responsible for the upkeep of all data in that subdomain. It has complete control over the data and can even divide and delegate its subdomain. The parent domain retains only pointers to the subdomain’s data sources in order to refer queries there. The domain hogwarts.edu, for example, is delegated to Hogwarts network administrators, as shown in the below diagram.
Not all organizations delegate their entire domain, and not all managers delegate their entire workload. A domain can have multiple delegated subdomains as well as hosts that do not belong in the subdomains. For example, the Acme Corporation (which provides most of the gadgets for a certain coyote) has a division in Rockaway and its headquarters in Kalamazoo, so it could have a rockaway.acme.com subdomain and a kalamazoo.acme.com subdomain. However, the few hosts in the Acme sales offices spread across the United States would fit better under acme.com than either subdomain.
Later, we’ll go over how to create and delegate subdomains. For the time being, it is sufficient to understand that the term delegation refers to the assignment of responsibility for a subdomain to another organization.
You’d be surprised at how many subdomains a business manages. Click on the link to view the Microsoft.com Subdomains.
This section may feel like we’re going over old ground. Perhaps we are. In fact, we will be expanding on a previously discussed topic in this section.
Name servers are programs that store information about the domain name space. Name servers typically have complete information about a portion of the domain name space (a zone) that they load from a file or another name server. The name server is then said to have zone authority for that zone. Name servers may also be authoritative for multiple zones.
As you can see, domains, domain names, DNS, and name servers all serve different functions. They all work together to make your internet surfing experience a bit easier.
The distinction between a zone and a domain is significant but subtle. All top-level domains, and many domains at the second level and lower, such as hogwarts.edu and google.com, are broken into smaller, more manageable units by delegation.
These units are called zones. The edu domain is divided into many zones, as shown in the below diagram , including the hogwarts.edu zone, the mit.edu zone, and the nwu.edu zone. There is also an edu zone at the top of the domain. It’s natural for the people in charge of edu to split up the edu domain; otherwise, they’d have to manage the hogwarts.edu subdomain themselves. Delegating hogwarts.edu to Hogwarts makes far more sense. What remains for those in charge of edu? The edu zone, which would contain mostly delegation information for subdomains of edu.
The above diagram depicts The edu domain broken into zones.
The hogwarts.edu subdomain is, in turn, broken up into multiple zones by delegation. Delegated subdomains include gt, sd, rt, ht, and others. Each of these subdomains is delegated to a set of name servers, some of which are also authoritative for hogwarts.edu. However, the zones remain distinct and may have a completely different set of authoritative name servers.
A DNS zone is a section of the DNS namespace managed by a specific organization or administrator. A DNS zone is an administrative space that enables more granular control of DNS components like authoritative nameservers.
A common misperception is to associate a DNS zone to a domain name or a single DNS server. A DNS zone can, in fact, contain multiple subdomains, and multiple zones can coexist on the same server. DNS zones are not required to be physically separated from one another; zones are solely used for control delegation.
A zone and a domain can have the same domain name but different nodes. The zone, in particular, lacks nodes in delegated subdomains. The top-level domain ca (for Canada) has subdomains ab.ca, on.ca, and qc.ca for the provinces of Alberta, Ontario, and Quebec, respectively. Name servers in each province may be delegated authority over the ab.ca, on.ca, and qc.ca subdomains. The domain ca includes all of the data in ca as well as all of the data in ab.ca, on.ca, and qc.ca. However, the zone ca only contains the data in ca (see Figure 2-10), which is most likely pointers to the delegated subdomains. And the zones ab.ca, on.ca, and qc.ca are distinct from the ca zone.
Consider the example of quidditch. Headmaster Dumbledore is in charge of everything at the school. And he delegated house maintenance to four house masters. As a consequence, all of the houses are subdomains of Hogwarts. And house masters are in charge of various tasks such as managing a quidditch team. Headmaster Dumbledore no longer has a list of each house’s players. It is not his responsibility to manage the house quidditch team. He had already assigned the task to the housemasters. The list(zone file in the house zone) of players is kept by the house masters(authority). They have access to the players’ information. And Dumbledore has a list (a zone file in the school zone) of all the house masters.
The domain hogwarts includes all of the data in Hogwarts as well as all of the data in gryffindor.hogwarts, slytherin.hogwarts, ravenclaw.hogwarts and hufflepuff.hogwarts. However, the zone hogwarts only contains the data in hogwarts, which is most likely pointers to the delegated subdomains. And the zones gryffindor.hogwarts, slytherin.hogwarts, ravenclaw.hogwarts and hufflepuff.hogwarts are distinct from the hogwarts zone.
However, if a subdomain of the domain is not delegated, the zone contains the domain names and data in the subdomain. As a result, the bc.ca and sk.ca (British Columbia and Saskatchewan) subdomains of the ca domain may exist but are not delegated. (Perhaps the provincial authorities in British Columbia and Saskatchewan aren’t yet ready to manage their own zones, but the authorities in charge of the top-level ca zone want to maintain namespace consistency and implement subdomains for all Canadian provinces right away.) As shown in Figure 2-11, the zone ca has a ragged bottom edge and contains bc.ca and sk.ca but not the other ca subdomains.
It is now clear why name servers load zones rather than domains: a domain may contain more information than the name server requires. A domain may contain data that has been delegated to other name servers. Because a zone is defined by delegation, it never contains delegated data.
Consider what would happen if a root name server loaded the root domain rather than the root zone: it would load the entire namespace!
However, if you’re just starting out, your domain will most likely not have any subdomains. In this case, because there is no delegation, your domain and zone contain the same data. It’s like one ring to rule them all, Or in your case one administrator to manage them all.
Even if you don’t need to delegate parts of your domain just yet, it’s useful to understand how the process of delegating a subdomain works. In general, delegation entails delegating responsibility for a portion of your domain to another organization. What actually occurs is the delegation of authority for your subdomains to various name servers. (Note that we said “name servers,” not just “name server”).
Instead of containing information in the subdomain you’ve delegated, the data in your zone includes pointers to the name servers that are authoritative for that subdomain. If one of your name servers is asked for data in the subdomain, it can now respond with a list of the appropriate name servers to contact.
That’s all for DNS.