Contact Us:
07002007332
CheapDeveloper
CheapDeveloper » Webmaster » Articles » Introduction to DNS Terminology, Elements, and Concepts

Introduction to DNS Terminology, Elements, and Concepts

11 December 2021, Saturday By Priyanka Boruah
116
0

Introduction

DNS, or Domain Name System, is often a very difficult part of learning how to set up websites and servers. Understanding how DNS works can help you diagnose problems with setting up access to your websites and expand your understanding of what's going on behind the scenes.

In this guide, we will discuss some of the fundamental concepts of the Domain Name System to help you understand how to set up your DNS. After completing this tutorial, you will be able to set up your own domain name or your own DNS server.

Before we get into configuring servers to convert your domain or configuring our domains in the control panel, let's take a look at some basic concepts of how DNS works.

On this page

Introduction

Domain terminology

How DNS works

Conclusion

Related: What is DHCP protocol

Domain Name System

Domain terminology

We should start by defining the terms. Although some of these topics may be familiar to you from other fields, there are many other terms used in the conversation about domain names and DNS that are not too often used in other computer fields. Let's start with a simple:

Domain Name System

The Domain Name System, better known as "DNS", is a network system that allows us to convert human-friendly names (usually alphabetic) into unique addresses.

Domain Name

A domain name is a human-friendly form of name that we are used to associating with an Internet resource. For example, "google.com" is a domain name. Some will say that the "Google" part is a domain, but in general we can think of this combined form as a domain name. 

The URL "google.com" is connected to a server owned by Google Inc. The domain name system allows us to connect to a Google server when we type "google.com" into a browser.

IP address

We call the IP address the network address of a node. Each IP address must be unique within its own network. When we talk about websites, that network is the entire Internet.

IPv4, the most common form of addresses, is written as four sets of numbers, each set containing up to three numbers, separated by a period. For example, "111.222.111.222" might be considered a valid IPv4 IP address. Using DNS, we concatenate a name with this address and save ourselves from having to memorize a complex set of numbers for each location on the network.

Top level domain

The top level domain, or TLD, is the most common part of a domain. Is the last part of the domain name on the right (separated by a period). Common top-level domains are "com", "net", "org", "gov", "edu" and "io".

Top-level domains are at the top of the domain name hierarchy. Certain companies have been given control over the management of top-level domains by the ICANN (Corporation for the Management of Domain Names and IP Addresses) structure. These companies can also distribute domain names under TLDs, usually through the domain registrar that registers the domain.

Knot

Within a domain, its owner can define its own sites that link to individual computers or services that are accessible through the domain. For example, most domain owners make their web server accessible through the root domain (example.com) as well as through a "host" defined as "www" (www.example.com).

You may have different definitions of nodes under the common domain. You can have API access through the "api" site (api.example.com) or FTP access by designating the site as "FTP" or "files" (ftp.example.com or files.example.com). Host names can be arbitrary as long as they are unique for a given domain.

Subdomain

The object associated with the nodes is called a subdomain. DNS works in a hierarchy. Top-level domains can have many domains under them. For example, the top-level domain "com" includes "google.com " and "ubuntu.com ". A subdomain is a domain that is part of a higher-level domain. In this case, we can say that "ubuntu.com " is a subdomain of "com". Typically, it is simply called a domain, or the "Ubuntu" part is called SLD, which means a second-level domain.

Likewise, each domain can control the "subdomains" that are under it. For example, you might have a subdomain for the history department at your school at "www.history.school.edu". In this case, the "history" part is considered a subdomain. The difference between a hostname and a subdomain is that a host points to a computer or resource, while a subdomain extends the parent domain. 

When reading about subdomains or nodes, you may notice that the leftmost portions of the domains are the most specific. This explains how DNS works, from most specific to least specific, as you read from left to right.

Fully Qualified Domain Name

The Fully Qualified Domain Name is often referred to as the FQDN, or Fully Qualified Domain Name. Domains in the DNS system can be defined in relation to each other and are essentially ambiguous. The FQDN is a fully qualified name that indicates its location in relation to the absolute root of the domain name system.

This means that it points to every parent domain, including the TLD. The correct FQDN ends with a period, indicating the root of the DNS hierarchy. An example FQDN is "mail.google.com." Sometimes the software that asks for the FQDN does not need a trailing dot, but a trailing dot is required to comply with ICANN standards.

DNS server

A DNS server is a computer dedicated to translating domain names into IP addresses. These servers do most of the work in the domain name system. Since the total number of domain transfers is too large for any server, each server can redirect the request to other DNS servers or delegate responsibility for a subset of subdomains that are under their responsibility.

DNS servers can be "authoritative", which means that they provide answers to queries about domains under their control. Otherwise, they can point to other servers or provide cached copies of data from other DNS servers.

Zone file

A zone file is a simple text file that contains the connection between domain names and IP addresses. DNS uses it to figure out which IP address to contact when a user requests a specific domain name.

Zone files reside on DNS servers and generally define the resources available under a particular domain or where this information can be requested.

Records

The records are kept within the zone file. In its simplest form, a record is a simple connection between a resource and a name. These records can connect a domain name to an IP address, define DNS servers and mail servers for a domain, etc.

How DNS works

Now that you are familiar with some of the terminology associated with DNS, the question is, how does the system actually work?

The system is very simple in general terms, but very complex if you go into details. Overall, it is a very robust infrastructure that was needed to adapt the Internet as we know it today.

DNS root servers

As discussed above, DNS is essentially a hierarchical system. At the top of this system is what we call the root DNS server. These servers are under the control of various organizations in agreement with ICANN (The Corporation for the Management of Domain Names and IP Addresses).

Currently 13 root servers are in operation. However, since there is an unthinkable number of names to translate every minute, each of these servers has a mirror. Interestingly, all mirrors for one root server share the same IP address. When a request is made to a specific server, it will be redirected to the closest mirror of that root server.

What are these root servers doing? They process requests for information about top-level domains. Therefore, if a request comes in about something that the DNS server cannot resolve, then the request is redirected to the root DNS server.

The root servers don't really know where the domain is located. They are, however, able to direct the requester to a DNS server that handles the desired top-level domain.

Thus, if a request for "www.wikipedia.org" is made to the root server, it will reply that it cannot find a result in its records. It will check its zone files to see if it matches "www.wikipedia.org". And it will not find them either. Instead, it will find a record for the top-level domain "org" and provide the requester with the address of the DNS server in charge of the "org" addresses.

TLD Servers

The requester will then send a new request to the IP address (provided to him by the root server), which is responsible for the required top-level domain.

Continuing with our example, a request would be sent to the DNS server in charge of information about the "org" domain to see if it has information about where "www.wikipedia.org" is located. Again, the requestor will look for "www.wikipedia.org" in their zone files. And they will not find this entry in their files.

However, they will find an entry that mentions the IP address of the DNS server responsible for "wikipedia.org". And this brings us much closer to the result.

DNS server on domain levels

At this point, the requester has the IP address of the DNS server that stores information about the actual IP address of the resource. He sends a new request to the DNS server asking if he can provide "www.wikipedia.org".

The DNS server checks its zone files and finds that it has a zone file associated with "wikipedia.org". Inside this file is an entry for the "WWW" site. This entry indicates the IP address where this node is located. The DNS server returns the final response to the request.

What is a public DNS server?

In the above scenario, we referred to the "requester". So what does that mean?

In almost all cases, the requester will be what we call a "public DNS server". This server is configured to send requests to other servers. Basically, it is an intermediary for the user who caches previous query results to improve speed and knows the addresses of root servers that can translate requests made for data that he no longer knows about. 

Typically, a user will have multiple public DNS servers configured on their computer system. Public DNS servers are usually provided by the ISP or other organizations. For example, Google provides public DNS servers that you can query. They can be configured on your computer automatically or manually.

When you enter a URL into the address bar of your browser, your computer first checks to see if it can find where the resource is locally. It checks the "nodes" of files on the computer and elsewhere. It then sends a request to the public DNS server and expects to get back the IP address of the resource. The public DNS server then checks its cache for a response. If he does not find what he needs, he will follow the steps indicated above.

Public DNS servers essentially compress the process of submitting a request for the end user. Clients just have to remember to ask the public DNS server where the resource is located and be sure they find the definitive answer.

Zone files

We have already mentioned "zone files" and "records" in the above processes.

Zone files are the way a DNS server stores information about the domains it knows. Each domain that the DNS server has information about is stored in a zone file. If the DNS server is configured to handle recursive queries like a public DNS server, it will find the answer and provide it. Otherwise, it will tell the user where to look next. The more zone files a server has, the more responses it can provide to queries.

A zone file describes a DNS "zone" which is essentially a subset of the entire DNS system. Typically, it is used to configure only one domain. It can contain a number of records that indicate where the resources for the requested domain are located.

The $ORIGIN zone parameter is equivalent to the highest authority level in the default zone. Thus, if a zone file is used to configure the domain "example.com.", Then the $ORIGIN parameter will also be set for that domain.

This is configured at the top level of the zone file, or can be specified in the settings of the DNS server file that references the zone file. In any case, this parameter describes what the zone will be responsible for.

Likewise, $TTL configures the "lifetime" of the information it provides. It is essentially a timer. A caching DNS server can use previously requested results to answer questions until the specified TTL expires.

Related: How to install Nginx on Ubuntu


Record types

There can be many different types of records in a zone file. We'll cover some of the more common (or required) types below.

SOA records

The zone's Start of Authority (SOA) record is a required record for all zone files. It must be the first entry in the file (although $ORIGIN or $TTL may appear above). It is also one of the most difficult to understand.

The initial zone entry looks like this:

domain.com. In SOA ns1.domain.com. admin.domain.com. (
                                             12083   ; serial number
                                             3h   ; refresh interval
                                             30m   ; retry interval
                                             3w   ; exiry period
                                             1h   ; negative TTL
)

Let's explain what each part means:

  • domain.com: This is the root of the zone. It indicates that the zone file belongs to the domain.com.domain domain. Often you will see it replaced with “@”, which is just a placeholder that replaces the contents of the $ORIGIN variable we learned about above.
  • In SOA: The "In" part stands for Internet (and will appear on many records). SOA is an indication that this is the initial record of the zone.
  • ns1.domain.com: This part defines the master server for this domain. The DNS server can be either master, that is, primary, or slave, or secondary. 
  • admin.domain.com: This is the email address of the administrator for this zone. The @ symbol is replaced by a period in the email address. If there is usually a period in the name part of an email address, this means that the "\" character in this part is replaced (your.name@domain.com becomes your \name.domain.com).
  • 12083: This is the serial number of the zone file. Each time you edit a zone file, you must increase this number. Slave servers will check if the serial number of the master server for the zone is greater than the one on their system. If so, the server will request a new zone file, and if not, it will continue serving the original file.
  • 3h: This is the update interval for the zone. This is the amount of time that the slave server will wait before asking the server master to change the zone file.
  • 30m: This is the repeat interval for this zone. If the slave server cannot connect to the master when the update period comes, it will wait for a given amount of time, and then it will repeat the request to the master server.
  • 3w: This is the expiration period. If the slave DNS server was unable to contact the master server within this time period, it will no longer return queries to the authoritative source for that zone.
  • 1h: This is the amount of time that the DNS server will cache the error if it cannot find the requested name in the file.

A and AAAA records

Both of these entries connect the host to the IP address. The "A" entry is used to connect a host with an IPv4 IP address, while the "AAAA" entry is used to connect a host for an IPv6 address.

The general format of these entries is:

host     IN IPv4_address
host     IN AAAA IPv6_address

Thus, if the SOA record accesses the main master server in "ns1.domain.com ", we need to connect this address to the IP address, since "ns1.domain.com " located in the zone domain.com, which this file defines.

The entry may look something like this:

ns1     IN A     111.222.111.222

Please note that there is no need to specify the full name. We can just specify the node (without FQDN), and the DNS server will fill in the rest according to the value of $ORIGIN. However, we could just as easily use FQDN:

ns1.domain.com.     IN A     111.222.111.222

In most cases, this is where you will specify your web server as "WWW":

WWW         IN A    222.222.222.222

We should also tell where the main domain is located. We can do this as follows:

domain.com.     IN A     222.222.222.222

We could also use the "@" symbol to refer to the main domain:

@     IN A     222.222.222.222

We also have the ability to transform everything under this domain, but not explicitly related to this server. We can do this with the "*" character:

*     IN A     222.222.222.222

All of the above also works with AAAA entries for IPv6 addresses.

CNAME record

The CNAME record specifies the alias for your server's canonical name (as defined by the A or AAAA record).

For example, we can have an A record that identifies the node "server1" and then we can use "WWW" as the alias for this node:

server1    IN A     111.111.111.111
www         IN    CNAME    server1

Be aware that some performance penalty comes with these aliases because they require an additional request to the server. In most cases, the same results can be achieved with additional A or AAAA records.

CNAME is recommended when you need to provide an alias to a resource outside the current zone.

MX record

MX records indicate the mail exchange servers for the domain. This helps the email messages arrive at your mail server correctly.

Unlike many other types of records, mail records generally do not attach a node to anything because they are zone-wide. They usually look like this:

      IN     MX 10 mail.domain.com.

Note that there is no hostname at the beginning. There is also an additional number in the record. This is the preferred number that helps computers determine which server to send mail to when multiple mail servers are specified. Lower values ​​have higher priority.

The MX record should, in fact, forward to the node specified in the A or AAAA record, and not to the one specified by CNAME.

Let's imagine we have two mail servers. There should be records that look something like

        IN     MX     10    mail1.domain.com.
        IN     MX     50    mail2.domain.com.
mail1     IN A     111.111.111.111
mail2     IN A     222.222.222.222

In this example, host "mail1" is the preferred exchange server. We could also write it like this:

        IN     MX     10     mail1
        IN     MX     50     mail2
mail1     IN A     111.111.111.111
mail2     IN A     222.222.222.222

NS records

This record type points to the DNS servers used for this zone.

You might ask, "Why does a zone file on a DNS server need to reference itself?" The DNS server is so convenient because it has multiple levels of caching. One reason for specifying DNS servers in a zone file is that the zone file may actually be served from a cached copy on another DNS server. There are other reasons why DNS servers need to refer to the DNS servers themselves, but we won't go into those details.

Like MX records, NS records are parameters for the entire zone, so they do not connect nodes either. They look like this:

        IN NS ns1.domain.com.
        IN NS ns2.domain.com.

You must have at least two DNS servers listed in each zone file in order to operate correctly if there is a problem with one of the servers. Most DNS server software will invalidate a zone file if only one DNS server is specified.

As always, consider the connection for hosts with A or AAAA records:

        IN NS ns1.domain.com.
        IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233

There are quite a few other record types you can use, but these are probably the most common types you will see.

Conclusion

You should now have a fairly good idea of ​​how DNS works. While the idea is generally pretty straightforward to understand, if you are familiar with the basic principles, some details may still be confusing to inexperienced administrators during the practice process.

Related: How to buy a domain - a guide to registering a domain name

Discuss

Read also:

AWS re:Invent 2021 Keynotes - AI/ML
03 December 2021, Friday
AWS re:Invent 2021 Keynotes - AI/ML
AWS re:Invent 2021: Keynotes
02 December 2021, Thursday
AWS re:Invent 2021: Keynotes
What is DHCP protocol
07 December 2021, Tuesday
What is DHCP protocol
What is a dashboard
25 November 2021, Thursday
What is a dashboard
Add a comment
Comments (0)
Comment
Partners