Guides about DNS like to assume their terms are understood. This page does not. Every entry here is checked against the relevant standard, and wherever a term is regularly misunderstood, the misunderstanding is noted right beside it.
The order runs from the fundamentals to the extensions.
A resolver that cannot perform all resolution itself and depends on a recursive resolver to undertake the actual resolution function. It typically lives in the operating system or the application and only issues the query.
Common misconception: People often assume the operating system stub resolver walks the delegation chain from the root servers itself. In fact it hands the entire resolution work to a recursive resolver.
A resolver that acts in recursive mode, either answering from a local cache or querying other servers until it has the final answer. In general it is expected to cache the answers it receives.
Common misconception: The word recursive describes only the service offered to the client, not the outward behaviour. Toward the authoritative servers the same resolver works iteratively, following referrals step by step.
A server that knows the content of a DNS zone from local knowledge and can answer queries about that zone without needing to query other servers. It sets the AA flag in the response header to 1 for such answers.
Common misconception: Not every answer from an authoritative server is authoritative: referrals to delegated child zones come with the AA bit set to 0. A server can also answer authoritatively without the parent zone having delegated authority to it.
An authoritative name server that answers queries for the contents of the root zone and forms an entry point into the root server system. The thirteen letter identities A through M are operated by twelve independent organisations.
Common misconception: Thirteen letters do not mean thirteen machines: on 2026-09-07 root-servers.org reported 2005 operational instances. The term mirror is deprecated here, the correct word is instance.
A zone that is one layer below the root, such as com or jp. Most TLDs are delegation-centric zones, that is zones consisting mostly of delegations to child zones.
Common misconception: From the point of view of the DNS protocol a TLD is nothing special, it is a zone like any other. The split into ccTLD, gTLD and others is purely a matter of policy.
The practice of making a particular service address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations. Each such location is called an instance.
Common misconception: Anycast is not a load balancer and does not guarantee the geographically closest instance, since routing decides by topology rather than distance. There is no hierarchy among anycast instances, each has the same level of authority.
An identifier for a single interface; a packet sent to a unicast address is delivered to the interface identified by that address. In a DNS context unicast means a server address announced from only one location.
Common misconception: Unicast identifies an interface, not a host; one host can carry several unicast addresses. The definition quoted from RFC 4291 comes from the IPv6 addressing architecture, but the concept is not limited to IPv6.
A structure which stores the results from previous responses so that identical requests need not be resolved remotely again. Resolvers are responsible for discarding old RRs whose TTL has expired.
Common misconception: A cache does not necessarily keep entries until the TTL expires; RFC 9499 notes an RRset can be flushed from the cache before the end of the TTL interval. Negative answers are cached too, which is negative caching per RFC 2308.
The maximum time to live of a resource record, that is the time interval in seconds the record may be cached before the source of the information should again be consulted. The value is an unsigned number from 0 to 2147483647.
Common misconception: The TTL is an upper bound, not a guarantee: a cache operator may shorten it for operational reasons and an RRset can be flushed early. All records in an RRset are required to carry the same TTL (RFC 2181, Section 5.2).
DNS response code 3 (Name Error), signifying that the domain name referenced in the query does not exist. Since names form a tree, nonexistence of a node implies nonexistence of the entire subtree rooted at that node.
Common misconception: NXDOMAIN means the name itself does not exist, not merely that the queried record type is missing; the latter is a NODATA answer with RCODE 0 and an empty answer section. It is likewise wrong to assume names can still exist beneath an NXDOMAIN name, since RFC 8020 rules that out.
The individual DNS data entry, consisting of owner name, type, class, TTL and RDATA; the information associated with a name is composed of such records. Records with the same owner name, class and type form an RRset.
Common misconception: The order of RRs in a set is not significant and need not be preserved by name servers or resolvers. An RRset is also always handled as a whole, and all of its records must carry the same TTL.
DNSSEC is a set of DNS extensions that add data origin authentication and data integrity to DNS answers through digital signatures, specified in RFC 4033, RFC 4034 and RFC 4035. RFC 9364 (BCP 237) states that using DNSSEC for origin authentication of DNS data is the best current practice.
Common misconception: DNSSEC does not encrypt anything. RFC 4033 Section 3 states plainly „These extensions do not provide confidentiality.“, so queries and answers remain readable on the wire; DNSSEC only makes them tamper evident.
DNSSEC validation is the process in which a resolver cryptographically verifies the signatures on an answer by building an authentication chain of DNSKEY and DS RRsets up to a configured trust anchor. The protocol behaviour of validating resolvers is defined in RFC 4035.
Common misconception: validation only protects zones that are actually signed. For unsigned zones a resolver can only prove that no signature exists, not that the answer is genuine.
The AD (Authentic Data) bit in the DNS header is set by a security-aware recursive name server when it has validated all RRsets in the Answer and Authority sections as authentic. RFC 4035 Section 3.2.3 forbids setting the bit unless all relevant RRsets are considered authentic.
Common misconception: a set AD bit is not proof. RFC 4033 Section 7 calls it only a hint and requires that the stub resolver „must trust both the recursive name servers in question and the communication channels between itself and those name servers“, because on an unsecured channel any attacker can set the bit.
A trust anchor is, per RFC 4033, „A configured DNSKEY RR or DS RR hash of a DNSKEY RR“ that a validating resolver uses as the starting point for building the authentication chain. RFC 5011 describes how trust anchors can be updated automatically and authenticated.
Common misconception: a trust anchor is not an X.509 certificate and does not come from the browser or operating system certificate store. In practice usually exactly one anchor is configured, that of the DNS root zone.
The Root Zone Key Signing Key is the IANA managed DNSSEC key that signs the key set of the DNS root zone and serves as the trust anchor for nearly all validating resolvers. The actively signing key is KSK-2017 with key tag 20326 („Signing since 2018-10-11“); its successor KSK-2024 with key tag 38696 is listed by IANA as „Pre-Publication“ and is scheduled to sign the zone from 11 October 2026.
Common misconception: the KSK does not sign individual root records, only the root zone DNSKEY RRset; the actual data is signed by the Zone Signing Key. As of 2026-09-07 the rollover to KSK-2024 has not yet taken place.
DNS over TLS (DoT) carries DNS messages inside a TLS session on the dedicated port 853, preventing eavesdropping and on-path tampering. RFC 8310 adds two usage profiles, Strict Privacy with mandatory server authentication and Opportunistic Privacy without that guarantee.
Common misconception: DoT in the opportunistic profile does not authenticate the server and therefore does not protect against an active attacker. Only the Strict Privacy profile of RFC 8310 refuses to resolve when encryption and authentication cannot be established.
DNS over HTTPS (DoH) maps each DNS query and response pair into an HTTP exchange over HTTPS, so DNS traffic is encrypted and hard to distinguish from other HTTPS traffic. The media type is application/dns-message, addressed via the URI template of a configured DoH server.
Common misconception: DoH does not fully hide which site you visit. First, the DoH operator still sees every query in the clear and can correlate it via HTTP cookies, header fingerprinting and IP address (RFC 8484 Section 8.2); second, the subsequent connection itself reveals the destination, since per RFC 8744 „The SNI extension is carried in cleartext in the TLS 'ClientHello' message“ and the server IP address remains visible.
DNS over QUIC (DoQ) carries DNS over dedicated QUIC connections on UDP port 853 with the ALPN token „doq“, offering confidentiality similar to DoT without TCP head of line blocking. RFC 9250 describes DoQ as a general purpose transport for stub to recursive, recursive to authoritative and zone transfer.
Common misconception: DoQ on UDP port 853 is not the same as DoT, which uses TCP port 853, and it is not DNS over HTTP/3 either. Both endpoints must explicitly negotiate DoQ via ALPN.
DNSCrypt is an open but non IETF protocol that, per dnscrypt.info, „encrypts, authenticates and optionally anonymizes communications between your DNS client and resolver“. Version 2 of the specification uses the X25519-XChaCha20Poly1305 construction and Ed25519 for signing resolver certificates.
Common misconception: DNSCrypt is not an RFC and not an IETF standard; it exists only as an individual Internet-Draft and its own protocol specification. It is also unrelated to DNSSEC, since it secures the transport path rather than the zone data.
Oblivious DNS over HTTPS (ODoH) inserts a proxy between client and DoH target, so the proxy knows the client IP address but not the content, while the target decrypts the content but only sees the proxy IP. The mechanism is published as Experimental in RFC 9230.
Common misconception: the protection depends on proxy and target not colluding or belonging to the same operator. If they collude, the separation of identity and content collapses.
EDNS(0) extends the DNS wire format in a backward compatible way through an OPT pseudo RR (type 41) in the additional section, enabling UDP messages larger than 512 bytes, extra flag bits and an extended RCODE space. The OPT record carries no DNS data, only control information.
Common misconception: the UDP payload size a client advertises only states its own receive capability; it does not guarantee that path MTU and firewalls will pass packets of that size. EDNS(0) is also not a security mechanism, only the carrier for options such as Padding, ECS or DNS Cookies.
EDNS Client Subnet (ECS) is an EDNS(0) option with which a resolver passes a truncated part of the client network prefix to authoritative servers so they can return geographically appropriate answers and signal the cache scope. RFC 7871 is Informational and documents a mechanism already in active use.
Common misconception: ECS undermines part of the privacy gain of encrypted DNS, because the user network information is passed to every authoritative server involved. RFC 7871 therefore explicitly recommends that the option be turned off by default in nameserver software.
With QNAME minimisation a resolver no longer sends the full original QNAME and QTYPE to an upstream authoritative server, but only the name stripped to one label more than the longest name for which that server is known to be authoritative. RFC 9156 is Standards Track and obsoletes RFC 7816.
Common misconception: QNAME minimisation only protects against upstream authoritative servers such as the root and TLD servers. Your own recursive resolver still sees the full name being queried.
The EDNS(0) Padding option (option code 12) lets clients and servers pad DNS messages by a variable number of octets so that message length reveals less. RFC 8467 recommends, experimentally, block length padding to a multiple of 128 octets for queries and 468 octets for responses.
Common misconception: padding is only useful inside an encrypted transport such as DoT, DoH or DoQ. On cleartext DNS it yields no privacy gain, because the content is readable anyway.
Encrypted Client Hello (ECH) is a TLS extension that encrypts the ClientHello under a server public key, hiding sensitive fields such as the SNI and the ALPN list. The required configuration is normally obtained through the HTTPS/SVCB DNS resource record.
Common misconception: ECH alone does not hide the destination. RFC 9849 states: „ECH is not in itself sufficient to protect the identity of the server. The target domain may also be visible through other channels, such as plaintext client DNS queries or visible server IP addresses.“
Server Name Indication (SNI) is the TLS extension by which a client tells the server, during the handshake, which host name it wants to reach, so that one server can host multiple virtual servers on a single IP address. It is defined in RFC 6066 Section 3.
Common misconception: without ECH the host name in the SNI travels in the clear even though the connection counts as HTTPS. RFC 8744 notes that monitoring increasingly relies on exactly „the cleartext SNI“ to identify which services a user accesses.
A DNS sinkhole is a resolver that deliberately does not answer queries for unwanted names truthfully, returning for example NXDOMAIN, NODATA or a redirected address in order to block connections to malicious infrastructure or ad and tracking domains. In BIND 9 this is implemented through Response Policy Zones, which the ISC documentation describes as „a form of DNS firewall“.
Common misconception: a sinkhole only blocks name resolution, not the connection itself. Anyone who knows the IP address directly or uses their own encrypted resolver in the device bypasses the sinkhole entirely; a synthesized answer also conflicts with DNSSEC validation.
Per RFC 9499 a forwarder is „A nameserver used to resolve queries instead of directly using the authoritative nameserver chain“; forwarding is „The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query“. RFC 9499 is BCP 219 and the current DNS terminology document.
Common misconception: forwarding is not blind relaying of packets but a resolver function with its own cache. Using a forwarder also shifts the trust question and the visibility of all queries to the upstream operator.
DNS rebinding protection filters out answers from public zones that point into private or local IP address ranges, so an attacker cannot turn a user browser into a proxy into the internal network. Unbound implements this with the private-address option, which removes matching A, AAAA, SVCB and HTTPS records from answers.
Common misconception: the protection applies only to names in public zones and can break legitimate cases such as split horizon setups or services that deliberately publish private addresses. Unbound therefore provides explicit exemptions via private-domain.
Every standard named above, in full text at the RFC Editor.