Introduction
DNS, acronym for Domain Name System, is the system that allows you to translate domain names into IP addresses.
Understanding how DNS works will help you diagnose problems related to the configuration of accesses to your websites and will allow you to get a clearer view of the logic behind Internet operations.
This guide will provide some fundamental concepts on DNS, useful for providing basic knowledge, and then explain how DNS can actually be configured and a zone file modified.
DNS: Terminology and definitions
First of all, it is advisable to be able to recognize all the different terms that will be encountered when dealing with this topic.
Domain Name System
The Domain Name System , better known as DNS, is the network system that allows you to translate names, written in natural language, into unique IP addresses.
Domain Name
The Domain Name ( Domain Name ) is the name, written in natural language, which is associated with a particular resource on the internet. To give an example: "google.it" is a domain name. Some would only define "google" as a domain name but, in general, it refers to the form combined with the term Domain Name .
IP address
The IP address is referred to as an addressable location on the network. Each IP address is unique within a specific network. The use of the term ‘network’ is because networks can also be built within a company but, when referring to websites, the network corresponds to the whole Internet universe.
IPv4 is the most common version of address format. It consists of 4 strings of 3 numbers with dots in between that concatenate them (eg: “111.222.333.444”).
Through DNS. these addresses can be mapped with names written in natural language and allow you to associate the addresses with them without having to remember all the numeric strings. It basically works as a kind of telephone book. Imagine what it would be like, for example, you had to remember the IP address of Google, Facebook or Wikipedia by heart in order to access their services every time!
Top-level Domain
Also commonly known as the ‘extension’ of the domain name, aTop-level Domain, or TLD, is the more general part of a domain. Simply, a TLD defines the suffix present at the end of the website name, right after a period. To give some examples, the suffixes are high-level domains: “.com”, “ it”, “.net”, “.org”.
Top-level domains are at the top of the domain name term hierarchy. Some groups handle high-level domain control on behalf of the Internet Corporation for Assigned Name and Numbers (ICANN ). These groups distribute domain names under certain TLDs, usually by registering a domain.
Hosts
Within a domain, the domain owner can define individual hosts, which identify individual computers or services across the domain. For example, many domain owners make their web server accessible both through the domain name (eg: example.com) and the definition "host" "www" (e.g.: www.example.com).
Other examples of "host" definitions can be "api" (api.example.com) or "ftp" (ftp.example.com). Host names can be chosen arbitrarily as long as they are unique to the domain.
Sub-Domain
The Sub-Domain (Subdomain) is a concept related to the hosts.
DNS is hierarchical, and top-level domains can have several domains under them. The ".com" TLD, for example, may have domains such as" google.com " or " youtube.com " under it. These last two examples can therefore be defined as subdomains of the “ .com ” TLD. Hence, in a nutshell a subdomain is nothing more than a domain part of a larger one.
In the domains used as an example, the name “ google ” will be referred to as a Second Level Domain , or SLD.
Fully Qualified Domain Name
A Fully Qualified Domain Name , or FQDN, is a unique domain name that specifies an absolute position of a node in the DNS Hierarchy. This is unlike normal domain names, which, as they are ‘relative’, can be ambiguous in a DNS system.
This “absolute” name includes all the components previously specified, including the TLD. By definition, an FQDN always ends with a period, which indicates the root of the domain tree hierarchy. An example could be “ mail.google.com ”.
These names may also be found with no final dot, but the ICANN standard provides for this.
Name Server
The Name Server is a computer that deals with the translation of domain names into IP addresses. These servers, for the most part, work in the DNS system. Since the total number of domains to be translated is too large for a single server, each of them can redirect requests to other servers or delegate responsibility for some subdomains.
According to this operation, the name servers can be ‘authoritative when they directly provide answers to questions about their domains or they can be ‘delegation’ when they refer to other servers from which they extrapolate the correspondence of names and addresses.
Zone File
A DNS zone file is a text file containing the mapping that links domain names to their corresponding IP addresses. Through this file, the DNS system identifies which IP addresses to pass when the user requests a certain domain name.
The zone file resides innameservers and, in general, defines the resources available under a specific domain orwhere to obtain certain information from.
Records
Records are inside the zone file. A record represents a match between a resource and a name. Records can be used for example to:
- Match a domain name to an IP address;
- Define a name server for a domain;
- Define the mail servers for a domain.
How DNS works
Now that you have a better understanding of DNS terminology, you will understand better how the system works.
The system is very simple when viewed from a high level perspective but, when it comes to more detailed information, understanding may be more complicated. However, it’s undoubtedly a very reliable and essential infrastructure for the proper functioning of the Internet, anyway.
Root Server
As mentioned before, DNS is given by a hierarchical system. At the highest level of the hierarchy, there are the root servers. These servers are controlled by various organizations which are ICANN delegated authorities.
There are currently 13 root servers in operation. However, since the matches to be resolved every minute are very high, each of these servers are "duplicates", but each duplicate shares the same IP address as the original. Consequently, when there are too many requests to the same root server, some of them are forwarded to its duplicates.
These root servers’ task is to handle requests for information on high-level domains. If the request came for a resource of a lower level than possible from the root server, then it would only be asked for the domain.
Root servers don't know where the domain is hosted. However, they will redirect the requestor to the name server that manages that specific high-level domain that was requested.
As this dynamic is not easily understood, it can be best explained with an example:
Imagine looking for the website “ www.wikipedia.org ”. Looking for the full name, Tìthe root server will not find the result in its zone file records. However, by searching only for the entry ".org", that is a TLD, it will return to the requester the name server responsible for all addresses withTLD equal to ".org" .
Servers TLD
Going back to the previous scenario, the request previously forwarded to the root server will now pass to the TLD responsible for this high-level domain (eg: “ .org ”). The root server had obviously provided the IP address to forward the request to in order to communicate with the selected TLD.
Looking through its files, the TDL will not find the record corresponding to the conjunction between the name " www.wikipedia.org " and its IP address but will find the address of the name server responsible for "wikipedia.org" .
You’re slowly getting closer to the result...
Domain-Level Name Server
At this point, the request is forwarded to the name server responsible for recognizing the IP address of the searched resource. Once again, going back to the previous scenario, you are requested if you know the IP address of “ www.wikipedia.org ”.
This time, in the zone file, the name server will find a match. The record for the host "www" will be found. This record will tell the IP address where the host is located andthe name server will finally reply with a result to the requester.
What is a resolving name server?
In the scenario used as an example, an “applicant” is often mentioned. This entity is usually nothing more than a resolving name server, that is to say, a server configured to query other servers. In more basic terms, its task is to act as an intermediary for the user by saving the results of previous queries in a temporary memory to speed up the process of searching for a resource on the network. It also knows the addresses of the root servers, so that it can trigger the series of requests that are then made in sequence to find what the user has asked for.
Internet service providers, also called ISPs ( Internet Service Providers ), usually provide some resolving name servers which are saved on users' computer files. For example, Google provides DNS servers that can be automatically or manually queried and configured on your PC.
When looking for a URL in the browser's address bar, the computer first checks whether it can find the IP address of the resource via its local files. One of the files usually affected by this check is the hosts file. The request is then sent to the resolving name server to get IP address of the resource back.
The resolving name server will then check its cache memory to see if it has the requested address, otherwise it will follow the steps already explained above.
Theresolving name servers then serve to simplify the end-user requests, allowing them to simply specify the required location of the resource to get the exact answer back, after several inspections.
DNS Zone File
In previous mechanics, you were introduced to zone files and records.
Zone files are how name servers store information about the domains they know. Each domain known by a name server is then stored in a zone file. Many requests, however, cannot be managed directly by querying a name server zone file.
As a result, a name server can directly provide the answer or suggest where to continue looking for the information.
The more zone files a name server owns, the more the name server will be able to respond to more requests without having to refer to other entities.
A zone file describes a DNS “zone”, which usually serves as the backbone of the entire DNS name system. It is usually used to set up one domain only and may contain a number of records that define where the resources for that domain are located.
The $ORIGIN parameter, belonging to a zone file, will be equal to the highest authority level of the zone, by default.
For example, if there was a zone file to configure the domain “ example.com ”, the $ ORIGIN parameter would be set to “example.com.”.
This parameter can be configured either at the beginning of the zone file or in the DNS server configuration file that refers to the zone file. In any case, this parameter will represent the zone the server name can have control on to manage the requests autonomously.
Similarly, the $TTL is a parameter that configures the lifetime of the information provided by the name server. It's basically a timer. The cache memory of a name server can hold the results of past requests for a certain amount of time until this TTL value expires.
DNS Record Types
In the zone file, it is possible to find different types of records. In this section, you will be introduced to some of the most common or mandatory ones.
SOA Record
The Start Of Autorithy , or SQA, record is a mandatory record in all zone files. It is in fact the first record to appear in the file and can only be preceded by the $ ORIGIN and $ TTL parameters. It is also one of the most difficult records to understand.
The beginning of an SQA record usually looks as follows:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
Analyzing each part:
- domain.com. : this is the rootzone. This entry specifies that the zone refers to the domain named “ domain.com ”. Often, the name will be replaced by an @. This wording suggests that the domain name is in the $ ORIGIN variable ;
- IN SOA: the “IN” portion indicates internet (and will be present in many records). The entry "SOA" indicates that it is the beginning of the SOA record;
- ns1.domain.com. : This entry defines the primary server name for this domain. Name servers can be primary or secondary, and if DNS is dynamic, a server must be primary. If DNS has not been configured this way, then, this will only be one of your primary servers;
- admin.domain.com. : This field contains the administrator's email address for this zone. The “@” value is replaced with a dot in the email address. If there is a dot in the address, it is replaced with a "/";
- 12083: This is the serial number for the zone file. Whenever a zone file is edited, the number has to be incremented for proper propagation of the zone file. Secondary servers will check if the serial number of the primary server for a zone is larger than that on their systems. If so, the new zone file is prompted. If not, the original file continues to be served;
- 3h: This is the update interval for the zone. It is the time the secondary server will wait for before querying the primary for zone file changes;
- 3w: This is the expiration period. If a secondary name server has not been able to contact the primary for the specified time interval, then it will not return responses as an authoritative source for this zone.
- 1h: This is the amount of time after which the name server will report an error if it cannot find the requested name in this file.
A and AAAA Records
These two types of records associate a host with an IP address. The "A" record is for connecting a host to an IPv4, while the "AAAA" record is for connecting a host to an IPv6.
In general, the format of such records looks as follows:
host IN A IPv4_address
host IN AAAA IPv6_address
Since the SOA records in the example recalled a primary server in“ ns1.domain.com ”, then it should match an IP address as“ ns1.domain.com ” is within the zone defined by the “ domain. com ".
The record may look as follows :
ns1 IN A 111.222.111.222
As you can see, it wasn't necessary to specify the entire name. Only the host may need to be specified, without the FQDN. The DNS server will fill in the rest with the value of the $ ORIGIN parameter . However, if you wanted to be semantically clear, you could also enter the internal FQDN, as in the following example :
ns1.domain.com. IN A 111.222.111.222
Most of the times, your web server will be defined as " www ":
www IN A 222.222.222.222
Communicating which address your base domain translates to is also possible. For example:
domain.com. IN A 222.222.222.222
As mentioned above, to refer to the base domain, " @ " may also be used:
@ IN A 222.222.222.222
It is also possible to write matches of anything under the domain that is not explicitly defined on this server. A "*" may be used as a wildcard:
* IN A 222.222.222.222
Obviously, all these indications also work with IPv6 addresses and, consequently, also serve to define “AAAA” records.
CNAME record
CNAME records are used to define aliases for your server's canonical names (already defined via an A or AAAA record).
For example, there may be an "A" record defining a host named "server1" using " www " as an alias for this host:
server1 IN A 111.111.111.111
www IN CNAME server1
Be careful as renaming can cause some performance degradation as translation from aliases to original names requires an extra query.
Most of the time, the same result can be achieved by adding multiple A or AAAA records.
The CNAME record can be useful when an alias is needed for a resource that is outside the current zone.
MX record
MX records are used to define the mail exchanges used for domains. This helps emails get to your server correctly.
Unlike other record types, email-related records do not match a host, as they apply to the entire zone. Usually, they look similar to:
IN MX 10 mail.domain.com.
As you can see, there is no host name preceding the string.
Note that there is an extra number in this entry. This is the preference number: a number that helps you decide which server to send an email to if there are multiple servers in charge of receiving messages. Smaller numbers have a higher priority.
The MX record should generally point to a host already defined by an A or AAAA record and not a CNAME record.
So, if there were multiple servers organized for receiving emails, the entries in the file would look as follows:
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 the example above, the host named “ mail1 ” is the preferred server in the email exchange.
The same also be written as follows:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
NS record
This type of record defines the name servers used for the area concerned.
You may wonder why a zone file, already contained in a name server, should have references that repeat the file-server association.
Part of the answers supporting this mechanic lie in the fact that these references allow to speed up some DNS processes. Also, as sometimes a zone file might belong to a temporary copy of the original server, the reference needs to be in clear text.
Like MX records, NS record parameters also refer to the entire zone and not to specific hosts. Such a record would look as follows:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
To make the system work properly in case one of the two servers experiences problems, at least two name servers in each zone should be defined. Many DNS servers in fact report an error if only one server is defined, thus defining the zone file not valid.
As usual, matches with hosts via A or AAAA records are also included:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
With this last record, you now know the most common records you might come across.
PTR record
PTR records are used to define a name associated with an IP address. Such records are, in practical terms, the opposite of A or AAAA records.
The unique feature of PTR records is that they start in the root “ .arpa ” and are delegated to the owners of the IP addresses. Regional Internet Registries (RIRs) manage the delegation of IP addresses to specific organizations or service providers. RIRs include APNIC, AQRIN, RIPE NCC, LACNIC and AFRINIC.
Here is an example of how a PTR record of an IP address, equal to 111.222.333.444, might look:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Below, however, it can be found an example of the translation of an IPv6 address of a Google DNS Server, shown in nibble format (a 4-bit format). This server will have an IPv6 address equal to 2001: 4860: 4860 :: 8888 .
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
Using the dig command combined with the -x flag,it is possible to identify the DNS name associated with an IP address that has been entered.
$ dig -x 8.8.4.4 +short
The command output will be the domain name associated with that IP address, present in the PTR record:
google-public-dns-b.google.com.
Internet servers use PTR records to enter domain names in access logs, make spam management decisions, and show details on other devices.
Popular email servers will check the PTR record of an IP address they received the email from. If the sender of the message does not have a PTR associated with their IP address, then the email may be rejected or labeled as spam. It is not important that the domain of the email matches the FQDN in the PTR but that, at least, that the PTR record is valid and matches an A record.
Normally, network routers on the Internet have a PTR record that corresponds to their physical location. This helps in network traffic diagnostics or tracking.
Many vendors offer dedicated servers or VPS services that give the customer the option to enter a PTR record for their IP address.
CAA records
CAA records are used to specify which certificate authorities, abbreviated to CA, are authorized to issue SSL / TLS certificates for your domain.
All authorities are required to check these records before issuing a certificate. If no record is present, any CA can issue a certificate. Otherwise, only the CA specified in the record can issue certificates for that domain. CAA records can be applied on individual hosts or on the entire domain.
An example of CAA record looks as follows:
example.com. IN CAA 0 issue "letsencrypt.org"
The host, IN, and record type (CAA) are fields that have already been encountered when studying DNS. The additional part that makes up a CAA record is the string ”0 issue“ letsencrypt.org ””. The string is made upof a flag ( 0 ), a tag ( issue ) and values ( “letsencrypt.org” ).
- Flags: are integers that indicate how a CA should manage tags it does not know. If the value is 0, the record will be ignored. If 1, the CA must refuse to issue the certificate .
- Tags: are strings that indicate the purpose of the CAA record. Tag values can be issue to authorize a CA to create certificates for a specific hostname, issuewild to authorize wildcard certificates, or iodef to define a URL when CAs report policy violations.
- Values: are strings associated with the tag. For issue and issuewild, the value will be the domain of the CA you are granting permissions to. For iodef this could be the URL of a contact form or a mailto: link to send feedback via email.
the dig command may be used to get the CAA record using the following options:
$ dig example.com type257
Conclusions
After reading the different steps in this guide, you should now have a good understanding of how DNS works and how to actually change it to set up your domain's DNS zone.
While the overall concept is relatively easy to learn, the detailed mechanics behind the Domain Name System may be more difficult for the less experienced administrators to understand and put into practice.