Overview of DNS Terminologies, Components, and Concepts

DNS (Domain Name System) is one of the crucial components driving the internet. Having a proper understanding of how DNS works can help diagnose problems with website configuration and broaden your understanding of what’s going on behind the scenes.

In this guide, we’ll talk about some fundamental concepts of DNS to provide you with a solid ground while working with your DNS configuration. This guide will also help set up your own domain name or DNS server.

Let’s begin!

Domain Terminologies

First, we need to establish an understanding of the terms we are going to use. You may already be familiar with some of them from other contexts. However, there are many specific terms when talking about domain names and DNS that are not discussed much in other areas of computing.

• Domain Name System

The domain name system (DNS, for short) is a networking system in place that translates human-friendly domain names to unique IP addresses.

• Domain Name

A domain name refers to the human-friendly name used to associate with an internet resource. For example, “cloudsigma.com” is a domain name. Some may argue that only the “cloudsigma” part is the domain name but generally, it refers to the whole.

The URL “cloudsigma.com” is associated with the servers owned by CloudSigma. When entering the URL to the web browser, it communicates with the DNS to connect to the target server’s IP address.

• IP Address

An IP address acts as a network address for a device connected to the network. Each IP address must be unique within the network. In the context of websites, the network is, most of the time, the entire internet.

There are two types of IP addresses:

• • IPv4: This is the most common form of IP address. It’s written as a set of four numbers, each set having up to 3 digits. Each set is separated by a dot. The range of IPv4 is from 0.0.0.0 to 255.255.255.255.

  • IPv6: It’s a more modern standard that was developed to solve the problem of IPv4 address exhaustion. IPv4 supports up to 232 unique addresses whereas IPv6 supports up to 2128 addresses. Any IPv6 address is written in hexadecimal digits. It can contain up to 32 digits, separated into 8 sections (4 digits each section). Each section is separated by a colon (:).

Top-Level Domain

A top-level domain (TLD for short) is the most general part of the domain. It refers to the furthest part of the right (separated by a dot). Some of the common top-level domains include:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

In terms of domain names, these domains are at the top of the hierarchy. ICANN (Internet Corporation for Assigned Names and Numbers) can issue a permit for certain parties’ control over top-level domains. With permission, these parties can distribute domain names under the TLD (usually via a domain registrar).

• Hosts

In the domain, the owner can specify individual hosts, referring to separate machines/services accessible through a domain. For example, it’s a common practice to make the web servers accessible through the bare domain ( example.com) and the “host” definition “www  ( www.example.com).

It’s possible to have additional hosts under the general domain, for example, API access through “api” host ( api.example.com), FTP access through “ftp” or “files” host ( ftp.example.com or files.example.com).

Note that the domain names are allowed to be arbitrary as long as they are unique within the domain.

• Sub-domain

A sub-domain is a subject related to hosts. DNS functions in a hierarchy. A TLD can have many domains under it. For example, “ example.com”, “ cloudsigma.com”, etc. are all under the “com” TLD. In that regard, a sub-domain is a reference to any domain that’s a part of the target domain. Thus, we can say that “example.com” is a sub-domain of “com”. Generally, the “example” portion is referred to as an SLD (second-level domain).

Similarly, a domain can control all the “subdomains” located under it. This is usually what “subdomain” is used to refer to. For example, “ history.example.com” is a subdomain of “ example.com”.

The key difference between a hostname and a subdomain is, a host defines a computer/resource whereas a subdomain extends the parent domain. Whenever we’re talking about subdomains or hosts, you can ensure it by looking at the left-most portion of a domain as it’s the most specific. That’s how DNS works: from the most specific (left-most side) to the least specific (the right-most side).

• Fully Qualified Domain Name

A fully qualified domain name (FQDN, for short) refers to an absolute domain name. In the DNS system, domains can be given relative to one another. This can lead to some ambiguity. An FQDN, however, is an absolute name referring to the absolute root of the domain name system.

It means that FQDN specifies each parent domain including the TLD. A proper example would be “ mail.google.com”. In specific cases, the FQDN may not end with a dot but it must have a trailing dot (required by the ICANN standards).

• Nameserver

A nameserver is a dedicated computer for translating domain names to IP addresses. Nameservers bear most of the loads in the DNS system. Because the total number of domain translation requests is too high to handle for a single server, the requests are often redirected to other nameservers to offset the pressure.

A name server can be “authoritative”, meaning it only gives answers to queries about domains under its control. Such servers can relay the request to other nameservers or serve a cached copy of other nameservers’ data.

• Zone File

A zone file is a text file containing the mappings between domain names and IP addresses. It serves as the database of the DNS system. This is the catalog that DNS uses to find which IP address to contact when completing a user request for a certain domain name.

Generally, the nameservers host the zone files and define the resources available under a single domain. It can also hold info about where to go to get that info.

• Records

A zone file comprises numerous records. Here, a record is defined as a single mapping between a resource and a name. Records can be a domain name mapping to an IP address, resources available under a specific domain, or references to places to get the info.

DNS in Action

So far, we have familiarized ourselves with some common terminologies involved with DNS. However, how does the system actually work? The system may appear very simple at a high-level view. Nonetheless, getting further into details will unravel its true complexity. Overall, the DNS system is important for the widespread adoption of the internet.

• Root Servers

DNS, at its core, functions in a hierarchy. At the top of the system reside the “root servers”. These servers are under the control of various organizations. The authority of these servers is delegated by ICANN (Internet Corporation for Assigned Names and Numbers).

As of now, there are about 13 root servers in operation. Because of the load, however, each of these servers is mirrored. It is important to note that all the mirror servers share the same IP address as the root server. Whenever any request is made to the root server, the request is redirected to the nearest mirror of that server.

What are the jobs of the root servers? They serve info about top-level domains. Whenever a low-level name server fails to resolve a request, it’s redirected to the root server of the domain.

However, the root server doesn’t actually know the location of the domain. It only redirects the request that will handle the specifically requested top-level domain. For example, if a request is made for “ blog.cloudsigma.com”, the root server won’t have it in its records. It will search its zone files but there won’t be any record for it. Instead, it will recognize the “com” TLD and redirect the requesting entity to the nameserver handling “com” addresses.

• TLD Servers

Continuing from our previous example, the requesting entity will now send the request to the IP address (provided by the root server). In the case of “ blog.cloudsigma.com”, the “com” name server will search its records in its zone files.

There won’t be a record corresponding to the request. However, it will find a record listing the IP address of the nameserver responsible for “ cloudsigma.com”.

• Domain-Level Nameserver

Now, the requesting entity has the IP address of the nameserver that actually hosts the info about “ blog.cloudsigma.com”. It will now send a new request to the server, asking to resolve “www.cloudsigma.com”.

Same as before, the nameserver will check its zone files and find out the one associated with “ cloudsigma.com”. Inside this file will reside an entry for the “www” host. This record describes where the host is located. The final answer is then relayed to the requesting entity.

• Resolving Nameserver

In the example, we mentioned a requesting entity. What is it? In most cases, the requester will be a “resolving nameserver”. It’s a server that’s configured to ask questions to other servers. It acts as an intermediary server for users. It caches the results to improve the speed.

Any user will usually have a couple of resolving name servers configured on their system. Generally, the resolving nameservers are offered by the ISP or other organizations. For example, Google offers public resolving DNS servers to query from. You can configure it manually to your system.

When entering a URL in the web browser, it looks for the location of the resource. First, the search is performed locally. This includes the “hosts” file (and some other locations). If not found, then the request is sent to the resolving nameserver. After receiving the request, the resolving name server searches its cache for the answer. If not found, then it goes through the steps mentioned before.

Resolving name servers simplifies the requesting process for the end-user. The client only has to ask the resolving name servers for the location of a resource. The nameserver will investigate and return the final answer.

• Zone Files

We already discussed the concepts of “zone files” and “records”. Well, how do they operate?

Zone files act as the database for the nameservers, storing the info about the domains they know about. All the domains that a nameserver knows about will be stored in its zone file. However, most requests coming to a nameserver aren’t resolved by the zone file. If the server configuration is to handle recursive queries (resolving nameservers, for example), then it will return the answer. Otherwise, it will redirect the requesting party to a different place to look next.

The more zone files a nameserver hosts, the more authoritative its answers will be. Zone files describe a DNS “zone” (a subset of the entire DNS naming system). Generally, a zone file contains the configuration data of just a single domain. It can have numerous records defining the location of the resources of the domain in question.

The $ORIGIN parameter of a zone is equal to the highest level of authority of the zone. For example, a zone file for “ cloudsigma.com” will have its $ORIGIN as “ cloudsigma.com”. The value of the parameter can be stored at the beginning of the zone file or the DNS server’s configuration. Either way, the parameter describes what zone the file is authoritative for.

The $TTL parameter sets the “time to live” info of the result it provides. It can be described as a timer that a caching server can use to keep track of the validity of the cached answers. If the TTL value runs out, the answer is no longer valid and discarded.

• Record Types

The zone files consist of numerous records. Now, there are different types of records. Next, we will go over some of the most common (and mandatory) types of records:

SOA Records

The Start of Authority (SOA, for short) record is mandatory in all zone files. It must be the first real record in the file. However, entries like $ORIGIN or $TTL are allowed to appear beforehand.

The SOA record is one of the more complex types of records. The structure of it looks something like this:

Let’s break it apart:

• • example.com: This portion defines the root of the zone. In this example, the zone file is for the domain “ example.com”. Sometimes, the value may be replaced with @ (a placeholder to substitute the value of $ORIGIN).

  • IN SOA: The term “IN” means “internet”. You will find it in many records. The term “SOA” indicates that it’s an SOA record.

  • ns1.example.com: This value holds the primary nameserver for the domain “ example.com”. Nameservers can be either primary or secondary. If it was configured with dynamic DNS, then there needs to be one “primary” server. If no dynamic DNS was configured, then it will be one of the primary nameservers.

  • admin.example.com: The email address of the zone’s admin goes here. Note that the @ is replaced with . here. If the original email address contains a dot in it, then it’s replaced with a \. For example, “ my.domain@example.com” would become “ my\domain.example.com”.

  • 12083: It’s the serial number of the zone file. Every time the zone file is edited, the number must be updated for the file to propagate properly. Secondary servers use this serial number to keep track of whether their own zone files are up-to-date.

  • 3h: It represents the refresh interval for the zone. Secondary servers will wait this amount of time before checking for zone file updates.

  • 30m: This value represents the retry interval of the zone. If a secondary server fails to connect to the primary server once the refresh period is up, it will wait this amount of time before polling the primary again.

  • 3w: This value represents the expiry period. If a secondary server fails to connect to the primary server for this amount of time, it will stop returning responses as “authoritative”.

  • 1h: This value represents the amount of time the nameserver will cache a name error if it wasn’t found on its zone file.

A and AAAA Records

These records establish a map between a host to an IP address. Here, the “A” record signifies the IPv4 mapping to the host and AAAA the IPv6 mapping.

This is the fundamental structure of the A and AAAA records:

In the SOA record example, we called the nameserver “ ns1.exampel.com”. Nameserver falls under the domain “ example.com”. Here’s what it’s A record would look like:

Notice that we didn’t have to provide the full name. With just the hostname (without the FQDN), the DNS server can fill in the rest with the value from $ORIGIN. However, we can still use the FQDN:

Here is how to define the web server as “www”:

We should also include the mapping to the base domain. The entry would look like this:

Alternatively, we can use the @ symbol to denote the base domain (instead of its full name):

It’s a good practice to include a wild card entry that enables the option of resolving anything under this domain that wasn’t defined explicitly:

The same structure applies to AAAA records. The only difference is the IPv6 addresses.

CNAME Records

CNAME records act as an alias for the canonical name for the server (defined by an A or AAAA record). Have a look at the following example:

Here, we used “server1” as an alias for defining the “www” name. Note that such shortcuts come with performance costs as the server has to run additional queries to get the final answer. Depending on the number of alias layers, this can easily cause a big performance cost. However, there’s one specific case that benefits from CNAME aliasing, for example, providing a resource outside of the current zone.

MX Records

MX records define the mail exchanges for the domain. It helps the email arrive at the server correctly. Unlike other records, MX records don’t map a host to something as they’re applicable for the entire zone. This is why MX records look something like this:

Notice that there’s no hostname at the beginning of the entry. You will also notice that there’s an additional value in the line. It’s the preference number that helps to decide which server to send the mail to (if there are multiple mail servers defined). The lower the number, the higher the priority.

An MX record should point to a host defined by A or AAAA record (not by CNAME). Keeping that in mind, if there are two mail servers configured, then the records would look like this:

In this example, judging from the preference number, “mail1” is the preferable server over “mail2”. We can further shorten the code by omitting the full domain name:

NS Records

These records define the nameservers for the particular zone. Now, the obvious question is, if the zone file resides within the nameserver, why does it require a reference to itself? One answer to the question is the multiple caching mechanisms of the DNS system. The zone file may actually be a cached copy on other servers.

Similar to the MX records, the NS records apply to the entire zone. Thus, they don’t have any specific host by default. NS record entries will look something like this:

It’s recommended to have two nameservers defined in case one server fails to operate correctly. Moreover, most DNS servers will reject a zone file if it contains only a single nameserver.

You should also include the mapping of the hosts with A or AAAA records:

PTR Records

PTR records are inverse of a classic A or AAAA record. These records are used for defining a name associated with an IP address. These records have a unique property as they begin at the .arpa root and represent the owner of the IP address. It’s RIRs (Regional Internet Registries) that distribute IP addresses to organizations and service providers. The RIRs include APNIC, AFRINIC, LACNIC, RIPE NCC, and ARIN.

For example, a PTR record for 111.222.333.444 would look something like this:

In the next PTR record example, have a look at the Google’s IPv6 DNS server 2001:4860:4860::8888:

We can use the dig tool with the flag -x to look up the reverse DNS name of an IP address. For example, check out the reverse DNS IP address of 8.8.4.4:

Internet servers use PTR records to keep track of domain names in log entries, take informed spam-handling decisions, and display easy-to-read info about other devices.

Commonly-used email servers will look up the PTR record of the IP address the email was sent from. If the PTR record is blank, then there’s a high chance of the email being spam (thus, rejected). Note that having a match between the FQDN and the PTR record’s domain name isn’t the concern. The important factor is whether a valid PTR record is associated with matching and corresponding forward A record.

Generally, network routers on the internet have PTR records corresponding to their physical location. For example, “NYC” or “CHI” are valid references for routers located in New York and Chicago. This technique is beneficial when performing a traceroute or MTR and reviewing the path the packets are taking.

CAA Records

These records specify the CAs (Certificate Authorities) that can issue SSL/TLS certification for your domain. Since September 8, 2017, All CAs are required to check the CAA records before issuing a certificate. If no CA record exists, then any CA may issue a certificate. Otherwise, only specific CAs are allowed to issue certificates. CAA records can either be applied to single hosts or an entire domain.

Here’s an example of a CAA record:

The CAA-specific portion of the entry is 0 issue "letsencrypt.org". There are three parts involved in this portion:

• Flags: It’s an integer value indicating how a CA should handle tags that it doesn’t understand. If the flag value is set to 0, then the record will be ignored. If the value is 1, then the CA must refuse to issue the certificate.
• Tags: These are strings denoting the purpose of a CAA record. As of now, valid values include issue (authorizing a CA to issue certificates for a specific domain), issuewild (authorizing wildcard certificates), and iodef (defining a URL where CAs report policy violations).
• Values: These are strings associated with the tag of the record. If the tag is issue or issuewild, the value will usually be the domain of the CA you’re granting the permission to. If the tag is iodef, it will be a URL of a contact form or a mailto: link for email feedback.

We can use the dig tool to fetch the CAA records:

For more in-depth info about CAA records, check out RFC 6844.

Final Thoughts

This guide describes various DNS-related terminologies. It also describes how all of the components go together. With this thorough overview in mind, you should have a good grasp of the functionality of the DNS system. While the general idea is simple and easy to understand, the intricacies become complex really fast. For inexperienced admins, it can be difficult to apply these concepts and strategies.

Are you a CloudSigma customer? Then check out managing and updating reverse DNS/PTR records for your CloudSigma infrastructure.

Happy Computing!