The previous post traced the DNS resolution journey — a recursive resolver working through root, TLD, and authoritative nameservers to get an answer. But what is that answer, exactly?
The answer is a DNS record — a structured entry in the authoritative nameserver’s zone file. There are dozens of record types; seven of them come up constantly in real work. This post covers those seven, shows how to query them with dig, explains glue records (the structural fix for a circular dependency at the heart of DNS), walks through the DNS wire format, and looks at how modern DNS adds encryption.
Record Types
A — IPv4 Address
The most fundamental record. Maps a hostname to an IPv4 address.
A single hostname can have multiple A records pointing to different IPs — this is how basic load balancing and geographic routing work at the DNS level. The client picks one (typically the first, though resolvers may vary).
AAAA — IPv6 Address
The IPv6 equivalent of A. Four times as many characters, the same idea.
Modern browsers perform a “Happy Eyeballs” race: they query for both A and AAAA simultaneously and connect via whichever responds first (preferring IPv6). If only an A record exists, the connection falls back to IPv4.
CNAME — Canonical Name (Alias)
A CNAME says “this name is an alias for another name.” The resolver follows the chain until it finds an A or AAAA record.
MX — Mail Exchange
Controls where email for a domain is delivered. MX records include a priority number — lower means higher preference. Mail servers try the lowest-priority MX first and fall back to higher values if it’s unavailable.
If a domain has no MX record, mail servers fall back to the A record. If a domain has MX 0 . (null MX, RFC 7505), it explicitly rejects all email.
TXT — Text Records
Free-form text attached to a name. Used for everything that doesn’t have its own record type: domain verification, SPF anti-spoofing, DKIM public keys, DMARC policy.
The v=spf1 record tells receiving mail servers which hosts are authorised to send email claiming to be from google.com. If you own a domain and send email from it, you need this — otherwise your messages are likely to be marked as spam.
NS — Nameservers
Delegates authority for a domain to a set of nameservers. These are what the TLD nameserver returns in referrals.
When you register a domain, you set its NS records at your registrar. This is what delegates DNS authority from the TLD registry to your nameservers. Changing NS records triggers a 24–48 hour wait because TLD nameservers cache them at long TTLs.
SOA — Start of Authority
Every DNS zone has exactly one SOA record. It contains administrative metadata: the primary nameserver, the responsible email address, the zone’s serial number (incremented on every change), and timing values for zone transfers.
Reading it left to right: primary NS is ns1.google.com, admin contact is dns-admin.google.com (the first . is @), serial is 606836917, refresh/retry/expire/minimum TTL follow. The serial is what secondary nameservers use to detect that a zone has changed and needs to be re-transferred.
dig: Your DNS Debugger
Beyond +short and basic queries, dig has flags worth knowing for debugging.
Use @ to bypass your system’s configured resolver and query a specific one directly. Useful for checking whether a propagation issue is with your ISP’s resolver or global.
NXDOMAIN (Non-Existent Domain) means the name doesn’t exist in DNS. The AUTHORITY section returns the SOA record of the parent zone so the resolver knows how long to cache the negative response.
Glue Records: Breaking the Circular Dependency
Here is a structural puzzle at the heart of DNS. Consider Google’s authoritative nameservers: ns1.google.com, ns2.google.com. The .com TLD returns these names in a referral. Your resolver now needs to query ns1.google.com — but to do that, it needs to resolve ns1.google.com first, which requires querying google.com’s authoritative nameserver… which is ns1.google.com.
Circular dependency.
Glue records break the loop. When you delegate a domain to nameservers under that same domain, the registrar requires you to provide the IP addresses of those nameservers. The TLD registry stores those IPs alongside the NS records. The TLD then includes them in the ADDITIONAL section of referral responses — before the resolver needs to look them up.
Glue records only exist when the nameserver hostname is under the domain being delegated. If Google used ns1.cloudns.net instead of ns1.google.com, there would be no circular dependency and no glue records needed.
The DNS Wire Format
DNS messages travel over UDP (port 53), typically. Each message — query and response — shares the same binary format.
A few things worth knowing about the wire format:
- Name compression — DNS uses pointer references within the message to avoid repeating long names.
www.google.comin the answer section typically stores a 2-byte pointer back to where the name appeared in the question section, saving bytes. - UDP limit — traditional DNS messages are limited to 512 bytes over UDP. Responses exceeding this set the TC (truncated) flag, and the client retries over TCP. EDNS0 (RFC 2671) extends this limit to 4096+ bytes, allowing larger responses (like DNSSEC signatures) over UDP.
- Port 53 — standard DNS uses port 53 for both UDP and TCP. DoH and DoT use different ports (443 and 853 respectively).
DoH and DoT: Encrypting the Query
Traditional DNS is plaintext UDP. Every DNS query you send is visible to your ISP, your network operator, and anyone observing your traffic. Your ISP can see every domain you look up — even if the subsequent connection is HTTPS.
Two standards address this:
DNS over TLS (DoT) wraps DNS in a TLS connection on port 853. The protocol is still DNS, just encrypted. Configured at the OS level (Android 9+ supports it natively via “Private DNS” settings; on Linux, via systemd-resolved).
DNS over HTTPS (DoH) sends DNS queries as HTTPS requests to a resolver’s HTTPS endpoint (typically https://dns.google/dns-query). From the network’s perspective, it’s indistinguishable from normal web traffic. Can be configured per-browser (Firefox and Chrome both support it) or at the OS level.
| DoT | DoH | |
|---|---|---|
| Port | 853 (distinct, blockable) | 443 (same as HTTPS) |
| Configured at | OS level | Browser or OS |
| Visibility | Encrypted, but identifiable as DNS | Indistinguishable from HTTPS |
| Provider | System resolver | Browser’s chosen resolver |