understanding the variety of resource records

To somehow associate an IP address with a domain, just a few basic resource records are enough. However, there are dozens of them, some can be friends or conflict with each other, others increase

safety

, but if they are configured incorrectly, everything stops working. This raises questions for users with little or no experience. In this article, we’ll figure out what types of resource records there are, why there are so many of them, and look at examples of adding them.

Use navigation if you don't want to read the entire text:

→ Required entries
→ Classic recordings
→ Service records
→ Records for enhanced security

Required entries

SOA

SOA (Start of Authority) is one of those records that all DNS zones need to comply with IETF standards. In addition to the obvious parameters (name and record type), it may contain other values.

• mname is the name of the primary server, where updates come from for secondary servers that store duplicate DNS records.
• rname — administrator email address. Please note that a dot is used here instead of the @ symbol.
• serial — zone copy number. When creating a zone, the default value is 1. Each time data is synchronized between servers, the value is increased. Thus, the larger the serial value, the newer the data on the server.
• refresh — frequency with which secondary servers request SOA record updates from primary servers. Specified in seconds.
• retry – frequency with which secondary servers can request updates from the primary if it does not respond.
• expire — time after which the secondary server stops responding to zone requests if it does not receive a response from the primary.

N.S.

NS (Nameserver) – The entry indicates which server contains the actual DNS records. Without correctly configured NS records, you will not be able to open a website or application, since you will not be able to obtain the domain's IP address.

Typically, a domain uses several NS records at once, simply because it is more reliable: if one server fails, you can turn to another. The servers themselves store copies of all other DNS records.

Classic recordings

As you might guess, these are records that are found everywhere. Most likely when starting a site or application on a cloud or dedicated server, you will use one of these records. In short, they all point to a destination address, which will ultimately be IPv4 or IPv6.

A

A record type that is used to associate a server's IPv4 address with a domain resource record. The value of the A-record consists only of the value field, so everything works extremely simply.

For example, we have two entries: example.com and shop.example.com. For the first, the value field contains the value 1.1.1.1, for the second – 2.2.2.2. When opening the site example.com, the browser will access server 1.1.1.1, and when opening shop.example.com, it will access entry 2.2.2.2, respectively.

AAAA

A record generally similar to A, but with the difference that the domain resource record is associated with the IPv6 address of the server. An example of an AAAA record value: 2001:db8:abc1::54.

CNAME

CNAME (Canonical Name) is a record type that associates an alias with an actual (canonical) domain name. CNAME records are typically used to link to domains that host content and subdomains like www or mail. In other words, CNAME, unlike A and AAAA, refers to a domain name, not an IP address.

The first value in the entry specifies the alias (usually a subdomain like www or mail) for which it is created. The second is the domain that the alias points to.

Thus, thanks to CNAME records, it is easy to use multiple services from a single IP address. The latter defines the A-domain record. If the IP address changes, it will be enough to change the A record without changing each of the CNAME records.

Practical example. You have a domain example.com, and you connect a CDN for the cdn.example.com subdomain: cdn.example.com CNAME uuid.selcdn.ru. Here uuid.selcdn.ru is the domain name of the CDN resource. You can't directly specify CDN IP addresses because you don't control them, and they can change dynamically. The domain name of the CDN resource is permanent.

There are various restrictions for a CNAME record.

• A CNAME record cannot be added for a primary name. For such purposes, it is worth using an ALIAS record.
• If a CNAME record has been added for a subdomain, another record cannot be added for it.
• If any other records have been added for the subdomain, then the CNAME cannot be added.
• CNAME cannot be used as a redirect, since an HTTP redirect cannot be organized within the DNS.

ALIAS

ALIAS records are essentially CNAME at maximum speed. They also copy the target domain's data, but have a few differences.

First of all, an ALIAS record can be added for the primary domain, and its name can be at any level, including the second. In addition, it does not conflict with other records within the same subdomain, including those with the same name (except A and AAAA).

Cloud storage example. There is a container into which we loaded the site, its main domain is like uuid.selstorage.ru. We need the site to open at example.com.

Let's write example.com ALIAS uuid.selstorage.ru. When you try to open example.com, magic happens.

1. The browser will make a request for A and AAA records for example.com.
2. Our DNS server, knowing about the ALIAS record, will start resolving the addresses of the target domain uuid.selstorage.ru and receive an IPv4 or IPv6 response.
3. The DNS server will return the set of IP addresses obtained in the previous step for example.com.
4. The browser will establish a connection to the cloud storage servers and open example.com located there.

When using ALIAS records, remember that a domain/subdomain cannot have an A or AAAA record. Additionally, ALIAS will break DNSSEC on the primary domain (@) because the @A and @AAAA responses will be missing RRSIG records. This in turn will break the resolution on all resolvers.

There is no draft or standard RFC for ALIAS, so this record type may exhibit different behavior from service to service.

We wrote more about CNAME and ALIAS records in a separate article. With examples of use and mini-guides on connection and configuration.

Service records

Indicate the type of service and its additional parameters. For example, they determine the location of the host or mail server, the preferred connection protocol, etc. In other words, in theory, the service can work without these records, but with them it will be more convenient, faster and safer to use.

MX

MX (Mail Exchange) is a record type that points to the mail server of a domain name. This allows external mail servers to determine where to send email. In other words, the entry answers the question where is your mailer.

The format of this entry contains two values: priority and value. The first field determines the priority of the server to which mail will be sent. It can have a numeric value (integer): the lower it is, the higher the priority.

The value field specifies the domain name or IP address of the incoming email server.

Let's look at an example. Let's say we have an MX record example.com, in which the value 203.0.113.102 is set to priority 10, and the value 198.51.100.5 is set to 20. In this case, when sending an email to info@example.com, it will be sent to server 203.0.113.102, and if it is unavailable – to server 198.51.100.5.

Multiple MX records are relevant when one domain has several mail servers. Creating an entry for each server with a priority helps distribute the load and/or reserve mail servers.

SRV

SRV (Service Record) is a type of record that identifies the location, that is, the host name and port number of servers for specific services. Essentially, such a record answers the question of where a service of this type is, what is its IP and port. SRV was invented so as not to create new types of records, as happened with MX.

The format of such a record is as follows:

_service._proto.name TTL class SRV priority weight port target.

This entry states sequentially:

• _service. — symbolic name of the service;
• _proto. — transport protocol (the most popular now are TCP or UDP, although others can be used);
• name — domain name for which the entry is valid;
• TTL is the time in seconds during which a resource entry in the server cache is considered relevant;
• class — class field (in SRV records the IN class is always used);
• SRV — record type (always SRV);
• priority – completely identical to what is used in MX type records: the lower the value, the higher the host priority;
• weight – determines the relative weight for entries with the same priority: the higher the value, the more likely the host is to be selected;
• port — defines the TCP/UDP port on which the service runs;
• target is the canonical name of the machine on which the service is running.

Example entry

: xxx.tcp.example.com 86400 IN SRV 10 5 5060 xxxserver.example.com

SVCB

This is a further development of the SRV record with the addition of other metadata required for network connection. These include the preferred protocol and its version, IP addresses and ports.

The main benefit of this type of record is that it improves DNS server performance and makes the site or application load faster. This happens by providing users with optimal servers, protocols and public keys.

SVCB records have two modes:

• AliasMode – delegates operational management of the resource;
• ServiceMode – Combines configuration information for an endpoint.

SVCB entries are of the form: SvcPriority TargetName SvcParams.

• SvcPriority is a number ranging from 0 to 65535. The lower the value, the higher the priority of this entry relative to others. A value of 0 enables AliasMode.
• TargetName – domain name.
• SvcParams is a list of parameters, each of which is either independent or a pair SvcParamKey=SvcParamValue.

SVCB and HTTPS records also provide IP addresses directly, without the client having to look at the A and AAAA records. To do this, you can add the ipv4hint and ipv6hint parameters to the entries.

Example entry: example.com 3600 IN SVCB 1. alpn=”h3,h2″ ipv4hint=”192.0.2.1″ ipv6hint=”2001:db8::1″

HTTPS

HTTPS records are a variation of SVCB with an emphasis on HTTPS connections. They also help speed up the loading of sites and applications. Unlike the legacy HTTP protocol, which only asked the user for an IP address, HTTPS can, for example, create an alternative connection to endpoints (HTTP/3), enable Encrypted ClientHello, and support non-standard TCP and UDP ports.

Over HTTP, all user requests are sent without any encryption, just as text. This applies to passwords, bank card details and any other information. That is, an attacker can simply read the text in a request or response and know exactly what information someone is requesting, sending, or receiving. With HTTPS, requests and responses are encrypted using TLS (SSL) and appear as a string of random characters.

Records for enhanced security

These records store a fingerprint of encryption keys or other data to prevent tampering. Obviously, this is necessary to improve security.

SSHFP

SSHFP (Secure Shell Fingerprint) is a record type that contains the key fingerprint used by the server when connecting via SSH. The record helps prevent MITM (Man-in-the-Middle) attacks and contains the algorithm, type and fingerprint fields.

The algorithm field specifies the server key fingerprint algorithm to use. May have the following meanings:

• 0 — reserved,
• 1 – RSA,
• 2 – DSA,
• 3 – ECDSA,
• 4 – Ed25519.

The type field specifies the type of hashing algorithm for the server's public key. Possible values:

• 0 — reserved,
• 1 – SHA-1,
• 2 – SHA-256.

The fingerprint field contains a hexadecimal representation of the hash function result of the server's public key.

In practice it all looks like this:

Here the SHA-1 fingerprint of the DSA public key of the host with the DNS name host.example.com is 123456789abcdef67890123456789abcdef67890.

CAA

CAA (Certification Authority Authorization) is a type of DNS record designed to determine the certification authorities that are authorized to issue SSL certificates for a specific domain name or subdomain.

Such records appeared as an additional security measure so that the certificate could not be issued by third parties. They could also be attackers who would be able to hack even a short-term web server to create a certificate. It can then be used, for example, to carry out MITM attacks.

The CAA record identifies the certificate authorities that are authorized to issue TLS certificates for the domain name. If multiple centers have authorizations, a CAA record must be created for each of them.

The record contains three fields: flags tag and value.

The flag value is a number that reflects the criticality of the entry. There are two possible values.

• 0—the entry is not critical. If the tag value cannot be recognized or the CA (Certification Authority) does not support this value, then issuing a certificate is at the discretion of the CA.
• 128 – the recording is critical. If the tag value cannot be recognized or the CA does not support the value, then certificate issuance is prohibited.

The tag field can have the following values:

• issue – defines the CA for which issuance of certificates for the domain/subdomain of the record is allowed.
• issuewild – defines a CA for which issuance of wildcard certificates for the domain/subdomain of the record is allowed.
• iodef – Defines the email address or URL that the CA should use to notify the DNS zone owner of an unauthorized attempt to issue an SSL certificate (mail format is mailto:support@example.com, URL format is HTTP(S)://example. com/caa-webhook).

The value of the value field depends on tag. With issue or issuewild values

specifies the name of the CA; if set to iodef, specifies the email address or URL.

Let's sort it out For example. Let's say the example.com record is set to 128 issue “aa.example.ru”. This means that only CA aa.example.ru can issue an SSL certificate for the example.com domain.

Thus, thanks to CAA records, you can determine a list of trusted CAs for a domain and subdomains, prohibit the issuance of certificates, and also indicate contact contacts in case of violation of the rules of the CAA record.

DNSSEC

DNSSEC (Domain Name System Security Extensions) is a set of IETF extensions (RFCs) for the DNS protocol. It is needed to ensure the authenticity (authenticity, completeness and accuracy) of data when resolving domain names.

DNSSEC uses public key cryptography. This allows you to determine that the response is provided by the owner of the DNS zone and not by a third party, similar to SSH or HTTPS keys.

To consider this type of recording and the intricacies of its work in detail, you will have to write a separate article. If the topic is interesting to you, let us know – we will prepare a publication with examples and pictures.

You will find detailed instructions for working with resource records (adding, changing, deleting, etc.) in the Selectel documentation.