DNS Records: A Guide from A to ALIAS

DNS (Domain Name System) — a distributed system that tells, by domain name, where a website is located, where to deliver mail, and who owns the domain. Each such response is stored in the domain zone as a record of a specific type. This article is a reference for record types. How to configure DNS for a website and mail step by step is covered in the series “Configuring DNS for mail and website”: basic A and MX records, SPF, DKIM and DMARC, setup and checking, BIMI.

Two principles: TTL and delegation

TTL — record time-to-live in cache

Each record has a TTL — the number of seconds resolvers and clients may cache the response before asking again.

For stable records (A, MX) TTL is usually set from an hour to a day. Before a migration, lower TTL in advance: see the “TTL during migration” section below.

Delegation and NS servers

The parent zone (for example, .ru or .com) delegates control of your zone example.ru to the servers listed in NS records. There must be at least two servers, preferably in different networks: this is required by RFC 2182 and the rules of most registrars. If one server stops responding, resolvers will query another.

Basic records

A name with a CNAME cannot have other records (RFC 1034, RFC 2181). Therefore a CNAME cannot be placed at the zone apex (example.ru): there are always SOA and NS records there.

Service records

NS — servers responsible for the zone

NS records exist in two places: at the registrar (in the parent zone, which is the delegation) and in the zone itself. They must match — a mismatch causes some resolvers to receive stale responses.

SOA — zone parameters

One per zone, describes the primary server, the responsible contact, and timers for secondary servers.

example.ru. IN SOA ns1.example.ru. admin.example.ru. (
    2025111101   ; Serial (YYYYMMDDNN)
    7200         ; Refresh — how often secondary servers check the zone
    3600         ; Retry — retry on failure
    1209600      ; Expire — when a secondary server stops answering without contact with the primary
    86400        ; Minimum — negative response TTL (RFC 2308)
)

Increment the serial number with each zone change, otherwise secondary servers will not pick up the update. The format YYYYMMDDNN (date and edit number for the day) is convenient but not mandatory. In cloud DNS providers the SOA is usually managed by the provider.

TXT — arbitrary text

Used for SPF, DKIM, DMARC and domain ownership verification:

example.ru. TXT "v=spf1 mx include:_spf.yandex.net -all"
example.ru. TXT "yandex-verification=abc123"
_dmarc.example.ru. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru"

Details about mail records — in part 2 of the DNS series.

CAA — who is allowed to issue certificates

The record restricts the list of certificate authorities that may issue a TLS certificate for the domain (RFC 8659):

example.ru. CAA 0 issue "letsencrypt.org"

If there are no CAA records, any CA may issue a certificate. About free certificate authorities — in the article “Beyond Let’s Encrypt”, about issuing via DNS — in “SSL certificates via DNS”.

PTR — reverse record

Maps an IP address to a name. It is stored in the in-addr.arpa zone (for IPv4) and is configured by the address owner — usually the hosting provider, not the domain zone. PTR is mandatory for a mail server: without it emails often go to spam.

SRV — service host and port

SRV indicates which host and port a service runs on:

_minecraft._tcp.play.example.ru. IN SRV 10 5 25565 mc.example.ru.

SRV is used by SIP, XMPP, Kerberos, LDAP in Active Directory and some games.

ALIAS (ANAME) and CNAME at the zone apex

The CNAME limitation is inconvenient when the zone apex must point to a platform name (for example, to the address of a cloud provider’s load balancer). DNS providers solve this in their own ways: they resolve the target name themselves and return ready A/AAAA records to the client.

This is not a standard record type from the RFCs, but a provider-specific feature: when moving to another DNS provider it will need to be reconfigured.

GeoDNS — a technology, not a record type

GeoDNS returns different answers depending on where the query came from: for example, users from Europe get a European server address, users from Asia get an Asian one. Location is determined by the resolver’s IP or by the client’s subnet if the resolver forwards it (EDNS Client Subnet, RFC 7871). Such routing is offered by CDNs and DNS providers, for example Route 53 (geolocation routing).

Other records

How to check records

dig NS example.ru +trace           # delegation from the root to your NS
dig A example.ru                   # website address
dig MX example.ru                  # mail servers
dig TXT example.ru                 # SPF and verifications
dig TXT _dmarc.example.ru          # DMARC
dig SOA example.ru                 # zone parameters, serial number
dig CAA example.ru                 # allowed certificate authorities
dig -x 192.0.2.1                   # PTR for the address
dig example.ru +dnssec             # DNSSEC signatures

To query a specific server rather than the resolver’s cache, specify it explicitly: dig A example.ru @ns1.example.ru.

TTL during migration

1. Two days before (or at least the current TTL) lower the TTL of the records being moved to 300 seconds.
2. Wait for the old TTL to expire: only after that will all resolvers start querying frequently.
3. Change the records.
4. Once everything is verified, restore the TTL to an hour or a day.

Summary

For a website and mail, most companies only need A/AAAA, MX, TXT (SPF, DKIM, DMARC), NS and CAA. SRV, ALIAS and GeoDNS are required for specific tasks: services on non-standard ports, the zone apex on a cloud platform, or traffic distribution by region.

Sources:

• RFC 1034 and RFC 1035 — DNS basics
• RFC 2181 — clarifications, including about CNAME
• RFC 2182 — selection of secondary DNS servers
• RFC 8659 — CAA
• RFC 9460 — SVCB and HTTPS
• Cloudflare: CNAME flattening
• AWS Route 53: alias records