EMZETT.DNS Records
In short: Records in a DNS zone that associate domains with specific information — most famously IP addresses, but also mail servers, text information, or aliases.
In more detail: Every DNS record has a type (e.g. A, AAAA, CNAME, MX, TXT, NS), a name, a value, and a TTL. A domain can have any number of records of different types; which name servers are authoritative for a domain, in turn, is defined via NS records.
In Depth
The most important record types
- A — domain → IPv4 address, by far the most common record type
- AAAA — domain → IPv6 address, the modern counterpart to A
- CNAME — domain → another domain name (alias); according to the standard, must not exist alongside other record types on the same name
- MX — domain → the responsible mail server, with a priority number when there are several records
- TXT — arbitrary free text, e.g. for domain verification or for SPF/DKIM/DMARC (email spoofing protection)
- NS — domain → authoritative name server, defines who has “the final say” over the zone at all
- Other, rarer types: SRV (service records for certain protocols like SIP/XMPP), CAA (defines which certificate authorities are allowed to issue SSL certificates), PTR (reverse DNS, IP → domain instead of the other way round)
The complete resolution path
A typical query works like this: a client asks its DNS resolver (often the one from the internet provider, or a public one like 1.1.1.1/8.8.8.8) for emzett-digital.com. If the answer isn’t already in the resolver’s cache, it first asks one of the 13 root server clusters (the top level of the global DNS hierarchy), which refers it to the .com TLD server. This, in turn, refers to the domain’s authoritative name servers named via the NS record, which finally return the matching A record. This entire path is called “recursive resolution”, because the resolver walks the complete chain on behalf of the client, instead of leaving each individual intermediate step to the client itself (which would theoretically also be possible — “iterative resolution”).
In practice, thanks to caching, this complete path usually only runs once per resolver: all following requests (from any clients using the same resolver) are answered directly from the cache until the respective TTL expires, without having to walk the complete chain again. This is also why DNS changes don’t take effect everywhere immediately — they first have to “work their way through” all caches, which can take until the original TTL expires.
Zone files and management
All records for a domain together form its “zone”, managed via a zone file at the respective DNS provider (e.g. Cloudflare, Vercel DNS, the registrar itself). A zone file follows a standardised text format with an SOA record (Start of Authority, containing metadata like the primary name server and a serial number for synchronisation) followed by the actual resource records. Changes to a zone are made via the provider’s web interface or API, and then propagate — depending on the TTL of the changed records — to all resolvers worldwide within seconds to hours.
Common pitfalls
A classic mistake is putting a CNAME record on the same name where an A or MX record already exists — this violates RFC 1034 and leads to unpredictable behaviour depending on the resolver. Likewise, many people forget to lower the TTL in good time before a planned DNS migration, which then makes the actual switch take hours instead of minutes to become visible everywhere.
See also: A Record, AAAA Record, CNAME, MX Record, TXT Record, NS Record, TTL