How does a DNS Records work?

The Domain Name System (DNS) ensures that users can enter a domain in the browser and arrive at their desired website. In fact, network par­ti­cipants primarily com­mu­nic­ate via IP addresses. However, since these are rather unwieldy, you only need to enter the website name as this is auto­mat­ic­ally trans­lated into the number sequence. How does this trans­la­tion work?

When you enter an internet address in the browser, the system first has to look up which IP address belongs to this domain. This sometimes occurs even in the computer’s memory itself, often in the internet provider’s database or other DNS servers, and in cases of un­cer­tainty, via one of the large root servers that monitor the entire Domain Name System as authority entities. In order to perform a name res­ol­u­tion, the DNS records, spe­cific­ally the resource records, must be searched for in the DNS and/or name servers. Here, each IP address (known to the server) is assigned a domain name.

The DNS has a hier­arch­ic­al and de­cent­ral­ised structure. At each level, there is a server that is re­spons­ible for its namespace. This means that in the search for www.example.com’s IP address, the root server only helps if it knows which server is re­spons­ible for the Top-Level Domain (TLD). In this way, the in­di­vidu­al levels are run through in order to perform the name res­ol­u­tion. This means that the IP address of the actual web server or mail server resides solely with the host itself. For this reason, it is important for website operators to un­der­stand the concept of resource records.

DNS records are primarily located in zone files. With respect to DNS, a zone denotes an or­gan­isa­tion­al area. It is possible for a domain to consist of a single zone. Extensive domains, however, are often divided into several zones. Each DNS server is re­spons­ible for a zone. If a client therefore wishes to activate a specific domain, it (or more spe­cific­ally, the DNS server) has a look in the zone files for the ap­pro­pri­ate records and forwards the request to a lower-level server until the final des­tin­a­tion is reached.

Resource records are struc­tured according to a simple system and coded in ASCII. There is a separate line for each DNS record. The records typically follow the following format:

The discrete in­form­a­tion is separated by a space and some kinds of in­form­a­tion are only optional. In certain types of records, ad­di­tion­al fields also appear. But what do the key record fields represent?

• <name>: The domain name is the name that the user enters into their browser.
• <ttl>: TTL stands for “time to live” and denotes the time (in seconds) that a record may be tem­por­ar­ily stored in the cache. After the time has lapsed, it cannot be ensured that the resource record is still current. This in­form­a­tion is optional.
• <class>: In theory, there are different classes of DNS records. In practice, however, the records always refer to the internet (marked as IN), which is why this in­form­a­tion is also optional.
• <type>: Different types of resource records appear in a zone file (for more on this, see below).
• <rdlength>: This optional field specifies the size of the sub­sequent data field.
• <rdata>: Resource data is the in­form­a­tion according to which the domain name can be resolved (such as the IP address).

The DNS record for the example.com web server thus looks like this:

A client can store the record for 12,879 seconds (around three and a half hours) in the cache before the in­form­a­tion must again be requested from the DNS server. It involves a DNS record on the internet (IN) and a type A record (A). The domain is resolved to an IP address.

Another notation is also possible:

This notation il­lus­trates that the computer with the name www is part of the example.com domain. This way, other computers such as mail or ftp can be placed under the origin domain.

A record type de­term­ines what kind of in­form­a­tion is located in the record. In addition to the res­ol­u­tion of domain names according to IP addresses, DNS records have other functions as well.

The largest portion of name res­ol­u­tion on the internet takes place via the type A record. An IPv4 address is located in its data field. Through these records, it is possible for the internet user to enter a domain name in the browser and for the client to send an HTTP request to the ap­pro­pri­ate IP address. Since an IPv4 address always has a size of 4 bytes, the value under rdlength – if specified – is always 4.

An AAAA record, also known as “quad A”, functions exactly like the A record. However, it uses an IPv6 address instead of an IPv4 address to resolve the name. Because IPv6 has a length of 128 bits (16 bytes), the data field length is also pre­defined here. The AAAA des­ig­na­tion is based on the fact that the data field has four times the length of an A record data field.

SOA stands for Start of Authority. The records for this type contain in­form­a­tion on the zone that is organised by the zone file and/or the DNS server. This is important – among other scenarios – during a zone transfer. Here, zone files are mirrored to other servers in order to prevent failures. The zone transfer regulates the periodic dis­tri­bu­tion of the original file. In this kind of DNS record, a serial number is therefore also placed next to the mailing address of the re­spons­ible ad­min­is­trat­or. This increases with each file update.

Under a CNAME record (canonical name record), one finds an alias – an ad­di­tion­al name for a domain. Using this, the record refers to an existing A record or AAAA record. With this type, the rdata field is filled with a domain name that was pre­vi­ously linked with an IP address in the file. In this way, different addresses can refer to the same server.

An MX record refers to a mail exchange or an SMTP email server. One or several email servers are defined here that belong to the relevant domain. When using several mail servers (for example, to offset a failure), they specify different priority levels. In this way, the DNS knows in which sequence the contact attempt should proceed.

The PTR record (pointer) is a DNS record that permits a reverse lookup. Through this technique, the DNS server can also provide in­form­a­tion regarding which host names belong to a specific IP address. For every IP address that is used in A or AAAA records, there also exists a cor­res­pond­ing PTR record. At the same time, the IP address is struc­tured in reverse sequence and is also provided with the name of a zone.

In the NS record – a zone file’s name server record – the jur­is­dic­tion for a specific zone is clarified. For this reason, this record is mandatory for each zone file. This resource record gives the DNS server in­form­a­tion on whether it is re­spons­ible for the request – thus requiring it to organise the relevant zone – and to whom it must forward the request.

The TXT record contains text that either is intended for human users as an in­form­a­tion source or is machine-readable in­form­a­tion. This DNS record gives an ad­min­is­trat­or the option of storing un­struc­tured Text (in contrast to the struc­tured data of the other DNS records). This could also include details about the company behind the domain.

Via the SRV record, a server can provide in­form­a­tion about other services (SRV). For this purpose, the service, including the port at which it can be reached, is specified. In addition, the used protocol forms part of the name. Via the DNS record, a client can receive in­form­a­tion on LDAP or XMPP services.

Through the LOC record, the location of the physical server can be disclosed. For this purpose, the latitude, longitude, height above sea level as well as an error deviation are specified at the end of the record.

In the zone file (a type of simple text file), all of the DNS records are listed. In order for the data to be correctly processed, specific guidelines must be observed. Otherwise the DNS cannot function, and the client will receive the SERVFAIL error message. For this reason, it is necessary to adhere to a special structure: Initially the zone name is specified, and then, in many cases, the TTL. Adding the time in­form­a­tion right here has the advantage that, in the in­di­vidu­al resource records, the in­form­a­tion can be omitted. The TTL is then valid globally for the entire zone.

The first DNS record is a SAO record. Without this, a zone file cannot function. Con­versely, a zone file is then also valid only if the SOA record is available. After that, there are the first records for the name server, and then the A and AAAA records.

If comments are to be added within the file – for example, to make work easier for other ad­min­is­trat­ors –semi­colons should be used. This way, in­form­a­tion is created about a DNS record without the server pro­cessing the text. You can insert empty lines to structure your records. These are also simply ignored by the system during the readout. One line is used per record; a line break finalises the record. If you want to have a record run over several lines, however, you should then add brackets.

In addition to those mentioned above, there are many other possible resource record types that can be found in the zone files – even if not all that often. The following table in­tro­duces all the types and provides some brief insight into their functions.