One Domain, Many Kinds of Record.

What a DNS record is

Everything a domain publishes lives in its zone, a list of records held by the domain's authoritative servers. Each record ties three things together: a name, a type, and a value, plus a TTL saying how long it may be cached. When your resolver looks something up, it does not fetch “the domain”; it asks for one specific type at one name and gets back only the records that match, exactly as traced in how DNS actually works.

That is why the same name can answer many ways. Ask example.com for its A record and you learn its IPv4 address; ask the same name for its MX and you learn where its mail goes. The name is shared; the type decides which answer you get.

The address records: A and AAAA

These are the ones your browser needs to open a connection. An A record maps a name to an IPv4 address like 93.184.216.34. An AAAA record does the same job for an IPv6 address, the longer hexadecimal form. A name commonly has both, and the device picks whichever it can use. Everything else in the zone exists to support or describe the domain; A and AAAA are what actually get you to the site.

Pointing one name at another: CNAME

A CNAME record makes a name an alias of another name rather than of an address. If www.example.com is a CNAME for example.com, a resolver that wants the address follows the alias and then looks up the target's A or AAAA. It is how one canonical name can be reached under several labels without repeating its address everywhere.

The one rule that trips people up: a CNAME cannot sit at the apex of a domain, the bare example.com, because the apex must also carry records like NS and SOA, and a CNAME is not allowed to coexist with them. Providers work around this with their own apex-alias features, or increasingly with the modern HTTPS record described below, but the plain CNAME belongs on sub-names only.

A close relative, DNAME, aliases an entire branch at once instead of a single name: point old.example.com at new.example.com with a DNAME and everything beneath it is redirected together. It is the tool for renaming or merging whole sections of a namespace.

Mail and metadata: MX and TXT

An MX record says where email addressed to the domain should be delivered, naming a mail host and a priority number so a sending server knows which to try first. It points at a name, not an address, and that name then resolves through its own A or AAAA.

A TXT record holds free-form text, which turned out to be enormously useful. It is where a domain publishes its email-authentication policies, SPF, DKIM, and DMARC, that let receivers tell genuine mail from forgeries, and where services drop the short verification strings that prove you control the domain. If you have ever “added a TXT record to verify ownership”, this is the one.

That authentication proves who sent a message, but not that it travelled encrypted. Two newer mechanisms close that gap: MTA-STS with TLS-RPT, published through TXT records, tells sending servers to require TLS and to report when it fails, and SMTP DANE, a TLSA record on the mail host, pins the mail server's certificate the same way DANE does for the web. Together they stop a network from quietly downgrading your mail to plaintext.

The plumbing: NS, SOA, and PTR

The NS records name the authoritative servers for the zone, the ones that hold the real answers; they are how the level above delegates a domain down to whoever runs it. The SOA, start of authority, sits at the top of every zone and carries its housekeeping: the primary server, an administrative contact, a serial number that changes with each edit, and the timers that govern how copies refresh.

A PTR record runs the lookup backwards, mapping an IP address to a name. It lives in a special reverse zone and is used for sanity checks, most visibly by mail servers confirming that a sending address resolves back to a sensible hostname.

Certificates and signatures: CAA and the DNSSEC records

A CAA record lists which certificate authorities are allowed to issue certificates for the domain, a guardrail so a mis-issued or fraudulent certificate is harder to obtain. It does not encrypt anything; it constrains who may vouch for the name.

A separate family of records, RRSIG, DNSKEY, and DS, exists purely to sign the others so a forged answer can be detected. They are the machinery behind DNSSEC, and rather than duplicate that here, the record-signing story lives in its own guide.

The modern records: HTTPS, SVCB, and TLSA

For most of its life DNS mainly answered “what is the address”. The records that changed that are recent, and they are why a zone in 2026 is part of how a secure connection is set up, not just how a site is found. If you are coming back to DNS after a few years, this is what is new.

The HTTPS record, and its general form SVCB (service binding), let a name say how to connect before the first handshake even begins: which protocols it speaks such as h3 for HTTP/3, which port, address hints, and, most importantly here, an ech= parameter that carries the keys for Encrypted Client Hello. A browser that reads this can jump straight to HTTP/3 and hide the site name inside the handshake, saving a round trip and closing a privacy leak in a single record. It also gives the apex the alias-like behaviour a CNAME could never provide there.

The TLSA record, the piece behind DANE, publishes which certificate or authority is legitimate for a name directly in DNS, so a client can refuse a technically-valid but wrong certificate. Where CAA tells authorities who may issue, DANE lets the client itself check what to trust. It only means anything when the zone is signed, because an unsigned TLSA could be forged as easily as the certificate it is meant to guard, which is why DANE and DNSSEC are always paired. Together, HTTPS/SVCB and TLSA are the difference between the DNS of a decade ago and the one worth running today.

Quick reference

These cover almost everything you will meet day to day, including the modern security records. There are more specialised types, but a domain that publishes these is fully wired for the web, mail, delegation, and certificates.

Best practice in 2026

Securing a domain is a few layers, not one. Records are the visible part, but DNSSEC, email transport, and the registrar account matter just as much. A short checklist of what “done right” looks like today.

One honest note on the horizon: post-quantum signatures for DNSSEC are still IETF drafts in 2026, so zone signing stays on Ed25519 or ECDSA for now. The post-quantum protection you can actually deploy today lives on the transport to your resolver, the X25519MLKEM768 exchange behind encrypted DNS, not in the zone's own signatures.