Basics
- DNS (Domain Name System)
-
The hierarchical naming system that maps human-readable domain names (like
example.com) to IP addresses and other resource records. The DNS is a distributed database operated by a network of authoritative nameservers and resolvers. - Domain
- A name registered under a top-level domain (TLD). A domain is a point of delegation in DNS, under which the owner can create any number of subdomains and records. Purchased and renewed through a domain registrar.
- TLD (Top-Level Domain)
-
The last segment of a domain name –
.com,.org,.co.uk,.io, etc. Managed by registries under ICANN oversight. Generic TLDs (gTLDs) and country-code TLDs (ccTLDs) are the two major categories. - Nameserver
- A server that answers DNS queries. Authoritative nameservers hold the actual records for a zone; recursive resolvers fetch records from authoritative servers on behalf of clients. A domain’s NS records point at its authoritative nameservers.
- Recursive resolver
-
A DNS server that takes a query from a client, walks the DNS hierarchy (root → TLD → authoritative), and returns the final answer. Resolvers cache results according to TTLs. Examples:
1.1.1.1,8.8.8.8, your ISP’s resolver. - Zone
- A contiguous portion of the DNS namespace managed as a single unit. A zone file lists all records for a zone (SOA, NS, A, AAAA, MX, and so on). Each zone is hosted on one or more authoritative nameservers.
- Record
- A single DNS data entry within a zone. Records have a type (A, AAAA, MX, CNAME…), a name, a TTL, and a type-specific value. A zone contains many records; changes to records are what DNS management is mostly about.
- TTL (Time To Live)
- How long, in seconds, resolvers may cache a record before re-querying the authoritative server. Common values: 300 (5 min), 3600 (1 hour), 86400 (1 day). Lower TTLs mean faster propagation of changes but more queries to the authoritative server.
- Propagation
- The process of DNS changes spreading across resolvers worldwide. Bound by the TTL of the previous record: after a record changes, resolvers continue serving the cached value until the TTL expires. Use a propagation checker to verify visibility across public resolvers.
Record types
- A record
-
Maps a hostname to an IPv4 address.
www.example.com A 203.0.113.10says www resolves to IPv4203.0.113.10. The most common record type. - AAAA record
- Maps a hostname to an IPv6 address. Exactly like A records but for IPv6 (128-bit) addresses. Pronounced "quad-A".
- CNAME (Canonical Name)
-
An alias from one hostname to another.
shop.example.com CNAME commerce-platform.netsays queries for shop should resolve as if commerce-platform.net had been queried. CNAMEs cannot coexist with other records at the same name, including MX. - MX record
-
Specifies the mail server for a domain. Includes a priority (lower = preferred).
example.com MX 10 mail.example.comtells sending servers to deliver to mail.example.com. - TXT record
- Arbitrary text data attached to a name. Heavily used for verification (domain ownership proofs) and email authentication (SPF, DKIM, DMARC all use TXT records).
- NS record
- Specifies the authoritative nameservers for a zone. Every zone must have at least two NS records. NS records at the parent zone (your registrar) point at your DNS provider; NS records within your own zone mirror that list.
- SRV record
-
Locates a service on a host + port, with priority and weight. Used by SIP, XMPP, Minecraft, Matrix, and other protocols that benefit from service discovery. Format:
_service._proto.name TTL SRV priority weight port target. - CAA (Certification Authority Authorization)
-
Restricts which Certificate Authorities may issue certificates for a domain.
example.com CAA 0 issue "letsencrypt.org"says only Let's Encrypt can issue certs for example.com. Checked by CAs before issuing; recommended for defence-in-depth. - PTR (Pointer)
-
Maps an IP address back to a hostname (reverse DNS). Used for IP → name lookups, most commonly required for mail servers to avoid being marked as spam. Lives in
in-addr.arpa(IPv4) orip6.arpa(IPv6) zones, managed by the IP-range owner. - ALIAS record
- Like a CNAME but resolvable at the zone apex (the bare domain). Resolves at query time to the target’s A/AAAA records and returns those to the client. Useful when CNAME is technically forbidden but you still want to point at a hostname rather than an IP.
- TLSA (DANE)
- Publishes the expected TLS certificate or public key for a service via DNS, enabling DANE (DNS-based Authentication of Named Entities). Requires DNSSEC to be trustworthy. Format includes usage, selector, matching type, and the certificate association data.
- DS record
- Delegation Signer – published at the parent zone to establish the DNSSEC chain of trust for a child zone. Contains a hash of the child’s KSK. Published by updating the DS record at your registrar after enabling DNSSEC.
- SOA (Start of Authority)
- Metadata about a zone – primary nameserver, responsible email, serial number, refresh/retry/expire/minimum timers. Every zone has exactly one SOA record; resolvers use it to negotiate caching and zone transfers.
DNSSEC
- DNSSEC (DNS Security Extensions)
- A suite of extensions that add cryptographic signatures to DNS responses, letting resolvers verify records haven’t been tampered with in transit. Protects against DNS spoofing and cache poisoning. Established via a chain of trust from root → TLD → your zone.
- KSK (Key Signing Key)
- A DNSSEC key used to sign other DNSSEC keys – specifically the DNSKEY record set. The KSK’s public key hash is published as the DS record at the parent zone, anchoring the chain of trust. Rotated less often than ZSKs (typically yearly).
- ZSK (Zone Signing Key)
- A DNSSEC key used to sign the actual records in a zone. Rotated more frequently than the KSK (every few months) so a compromise doesn’t affect long-lived records. The ZSK is signed by the KSK.
- DNSKEY record
- Publishes the public portion of DNSSEC signing keys (KSK and ZSK) in the zone. Resolvers fetch DNSKEYs to verify signatures on other records. The DS record at the parent zone refers to the KSK by its hash.
- RRSIG (Resource Record Signature)
- The signature on a record set, produced by the ZSK (or KSK for the DNSKEY set). Resolvers verify RRSIGs against the corresponding DNSKEY to confirm records are authentic. Present alongside every signed record set in a DNSSEC-enabled zone.
- NSEC / NSEC3
- Records that enable DNSSEC to prove a name does not exist (without revealing information about all other names). NSEC3 hashes names before publishing them, making zone-walking harder. NexDNS uses NSEC3 by default.
- NSEC3
- A variant of NSEC that hashes record names before publishing them, making it harder for attackers to enumerate all names in a zone. NSEC3 is the recommended choice for public zones.
- Chain of trust
- The cryptographic linkage from the root zone (whose KSK is distributed out-of-band) through each TLD and down to a specific zone. Resolvers validate signatures link-by-link: root → TLD → your zone. Breaks if the DS record at any parent is missing or stale.
Email authentication
- SPF (Sender Policy Framework)
-
A TXT record that lists which servers are allowed to send email on behalf of a domain. Receivers check SPF during mail delivery; mismatches contribute to spam scoring. Format:
v=spf1 include:_spf.example.com ~all. - DKIM (DomainKeys Identified Mail)
-
Cryptographic signature added to outgoing email by the sending server, verifiable via a public key in a TXT record at
selector._domainkey.example.com. Proves the message wasn’t tampered with in transit and originates from the claimed domain. - DMARC (Domain-based Message Authentication, Reporting & Conformance)
-
A policy layered on top of SPF and DKIM that tells receivers what to do when a message fails authentication (none / quarantine / reject) and where to send aggregate reports. Published as a TXT record at
_dmarc.example.com.
Operations
- Zone transfer
- Copying a zone from one nameserver to another. AXFR copies the whole zone; IXFR copies only the changed records since a given serial number. Used between master and slave nameservers to keep them in sync.
- AXFR
- Full zone transfer – a secondary/slave nameserver requests the entire zone from the primary/master. Rarely exposed publicly; typically restricted by IP ACL or TSIG. Useful for one-off migration between DNS providers.
- IXFR
- Incremental zone transfer – the secondary requests only the changes since a given SOA serial. More efficient than AXFR for zones with frequent small updates. Falls back to AXFR if the primary cannot satisfy the incremental request.
- Master zone (primary zone)
- A zone whose records are authored directly on the nameserver (as opposed to being transferred from another source). Most zones are master zones on their DNS provider. On NexDNS, you create master zones through the panel, API, or CLI.
- Slave zone (secondary zone)
- A zone whose records are transferred from another nameserver (the master) via AXFR/IXFR. Used to mirror an existing zone for redundancy or to stage a migration. NexDNS supports slave zones on Pro plans and above.
Modern protocols
- DoH (DNS over HTTPS)
- DNS queries encapsulated in HTTPS, making them indistinguishable from ordinary web traffic and immune to on-path inspection. Used by browsers, operating systems, and privacy-focused resolvers. DoH is a resolver-side protocol; authoritative servers like NexDNS answer the resolver’s underlying DNS query.
- DoT (DNS over TLS)
- DNS queries over a dedicated TLS connection on port 853. Similar privacy properties to DoH but distinguishable by port, so easier to block in restrictive networks. Like DoH, this is resolver-side; authoritative servers are not directly involved.
- ECH (Encrypted Client Hello)
- A TLS 1.3 extension that encrypts the ClientHello, preventing network observers from learning which site a client is connecting to (previously leaked via SNI). Requires the site to publish an HTTPS-type DNS record with ECH parameters.
- EDNS (Extension Mechanisms for DNS)
- A set of extensions to the original DNS protocol that allow larger message sizes, additional flags, and new options without breaking compatibility. Required for DNSSEC; EDNS Client Subnet (ECS) is used by some providers for geo-aware responses.