DNS Records: How Do 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 participants primarily communicate via IP addresses. However, since these are rather unwieldy, you only need to enter the website name as this is automatically translated into the number sequence. How does this translation 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 uncertainty, via one of the large root servers that monitor the entire Domain Name System as authority entities. In order to perform a name resolution, the DNS records, specifically 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 hierarchical and decentralized structure. At each level, there is a server that is responsible 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 responsible for the Top-Level Domain (TLD). In this way, the individual levels are run through in order to perform the name resolution. 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 understand the concept of resource records.

DNS records are primarily located in zone files. With respect to DNS, a zone denotes an organizational 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 responsible for a zone. If a client therefore wishes to activate a specific domain, it (or more specifically, the DNS server) has a look in the zone files for the appropriate records and forwards the request to a lower-level server until the final destination is reached.

Resource records are structured 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 information is separated by a space and some kinds of information are only optional. In certain types of records, additional 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 temporarily stored in the cache. After the time has lapsed, it cannot be ensured that the resource record is still current. This information 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 information 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 subsequent data field.
• <rdata>: Resource data is the information 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 information 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 illustrates 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 determines what kind of information is located in the record. In addition to the resolution of domain names according to IP addresses, DNS records have other functions as well.

The largest portion of name resolution 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 appropriate 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 predefined here. The AAAA designation 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 information on the zone that is organized 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 distribution of the original file. In this kind of DNS record, a serial number is therefore also placed next to the mailing address of the responsible administrator. This increases with each file update.

Under a CNAME record (canonical name record), one finds an alias – an additional 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 previously 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 information 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 corresponding PTR record. At the same time, the IP address is structured 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 jurisdiction for a specific zone is clarified. For this reason, this record is mandatory for each zone file. This resource record gives the DNS server information on whether it is responsible for the request – thus requiring it to organize 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 information source or is machine-readable information. This DNS record gives an administrator the option of storing unstructured Text (in contrast to the structured 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 information 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 information 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 given 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 information right here has the advantage that, in the individual resource records, the information 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. Conversely, 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 administrators –semicolons should be used. This way, information is created about a DNS record without the server processing 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 finalizes 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 introduces all the types and provides some brief insight into their functions.