DNS Glossary: Encrypted DNS and DNSCrypt Terms in Plain English

DNS in simple terms

DNS in simple terms is the internet’s lookup service. Your device asks for a name such as example.com, a resolver finds the matching record, and the answer is usually an IP address to connect to. Classic DNS sends that question and answer unencrypted, which is the problem every encrypted protocol in this glossary tries to solve.

DNS glossary: protocols and transports

Plain DNS

The original DNS transport: unencrypted messages over UDP or TCP on port 53, sometimes written Do53. Anyone on the network path can read the questions and answers, and anyone able to inject packets can try to forge a reply. Every encrypted protocol below exists to protect this hop between your device and the resolver.

DNS over TLS (DoT)

Defined in RFC 7858 from May 2016, DoT wraps normal DNS messages in a TLS session over TCP. It uses its own port, 853, which makes it easy to recognise and, for networks that dislike it, easy to block. Android’s Private DNS setting uses DoT, and you configure it with a resolver hostname.

DNS over HTTPS (DoH)

RFC 8484 from October 2018 sends DNS messages as HTTP requests over TLS, normally on port 443 like any website. The resolver is configured as a URL, such as https://dns.quad9.net/dns-query. Because it looks like ordinary HTTPS, DoH is harder to block selectively. Windows 11 and Apple platforms support it natively without extra software.

DNS over QUIC (DoQ)

RFC 9250 from May 2022 carries DNS over a dedicated QUIC connection on UDP port 853, negotiated with the ALPN token “doq”. QUIC avoids the head-of-line blocking of TCP, where one lost packet stalls everything behind it. Sharing port 853 with DoT, it is about as easy for a network to filter as DoT.

DNSCrypt

A protocol built only for DNS, specified on dnscrypt.info. The client authenticates the resolver with a provider public key instead of a certificate authority, and encrypts each query with X25519 and XChaCha20-Poly1305. It runs over UDP and TCP, with port 443 recommended for both. dnscrypt-proxy is its best known client.

PQDNSCrypt

The post-quantum DNSCrypt variant defined in the current draft specification. It uses X-Wing, which combines ML-KEM-768 with X25519, so query confidentiality holds even against a future quantum computer. Its certificates are much larger, 1,320 bytes in total. dnscrypt-proxy supports it from version 2.1.17 and enables it by default with compatible servers.

Anonymized DNSCrypt

An extension to DNSCrypt v2 that sends each encrypted query through a relay. The relay forwards packets it cannot decrypt, and the server only ever sees the relay’s address, never yours. Choosing relays and servers run by different operators matters, because one operator running both could link the two sides back together.

Oblivious DoH (ODoH)

An experimental protocol, RFC 9230 from June 2022, built on DoH. The client encrypts the DNS message to the target resolver’s HPKE public key and sends it through a proxy. The proxy sees your IP address but not the query; the target sees the query but not your address, as long as the two do not collude.

DNSSEC

DNS Security Extensions, introduced in RFC 4033, let zone owners sign their records so that a validating resolver can prove an answer was not forged or altered. DNSSEC deliberately provides no confidentiality: it proves authenticity, while encrypted transports provide privacy. Using both together protects the answer itself and the path it travels.

DNS glossary: resolvers and servers

Resolver

Any software that turns a question about a name into an answer. RFC 9499 notes that the word is ambiguous and needs context, because it covers the small client in your operating system as well as large public services. When people say “my DNS server”, they almost always mean the recursive resolver their device queries.

Stub resolver

The minimal resolver built into an operating system or application. RFC 9499 defines it as a resolver that cannot perform all resolution itself and depends on a recursive resolver to do the work. When you change DNS settings on a laptop, you are telling its stub resolver which recursive resolver to ask.

Recursive resolver

A resolver that does the full job: it walks from the root to the authoritative servers, follows referrals, caches the results and returns the final answer. Public services like Quad9 or Cloudflare’s 1.1.1.1 are recursive resolvers. Because they see every query you send, choosing one is mostly a question of trust.

Authoritative server

A server that holds the actual content of a zone and answers for it with authority. Recursive resolvers ask authoritative servers on your behalf. Encrypted DNS protocols such as DoH and DNSCrypt normally protect only the hop between you and the recursive resolver, not the onward queries to authoritative servers.

Open resolver

RFC 9499’s term for a resolver that accepts queries from nearly any client. Public resolvers are open on purpose; many others are simply misconfigured. The public servers in the resolver directory are deliberate open resolvers that publish DNS stamps, so clients can verify them and pick the protocol they prefer.

Forwarder

A resolver that passes queries to another resolver instead of resolving them itself. RFC 9499 notes that forwarders often sit between stub resolvers and recursive servers, which is exactly where a home router or dnscrypt-proxy usually lives. A forwarder can add caching, filtering or encryption to everything that passes through it.

Policy-implementing resolver

A recursive resolver that changes some answers on purpose, for example to block malware or adult content. RFC 9499 notes that a stub resolver usually has no idea whether such a policy applies. Quad9’s main address and Cloudflare’s 1.1.1.2 are examples; dnscrypt-proxy avoids them unless require_nofilter is set to false.

Bootstrap resolver

A plain DNS resolver that dnscrypt-proxy uses only for its own startup needs, such as resolving the hostnames of DoH servers or downloading resolver lists. It is set with bootstrap_resolvers, which version 2.1.0 renamed from fallback_resolvers. Your regular queries never go to it once the encrypted servers are up and reachable.

Relay

In Anonymized DNSCrypt, a server that receives an encrypted query with a short header naming the target server, then forwards it over UDP. It never holds the key, so it learns nothing about the query. Relays have their own stamp type, 0x81, and the route builder pairs them with servers.

DNS terms for records and messages

Resource record

The basic unit of DNS data: a name, a type, a class, a TTL and the record data. A set of records with the same name, class and type forms an RRset, which is also the unit DNSSEC signs. A, AAAA, CNAME, MX and TXT are the record types you meet most often.

TTL

Time to live, the maximum number of seconds a record may be cached before a resolver must ask again. Short TTLs let changes spread quickly; long ones reduce lookups and latency. dnscrypt-proxy caches answers and, since version 2.0.1, counts the TTLs down so that clients always see the remaining lifetime.

TXT record

A record type that carries free-form text strings. DNSCrypt reuses it in an unusual way: a resolver answers a TXT query for its provider name with binary certificates, one per record, without hex or base64 encoding. Plain TXT records also let the project publish its Minisign public key at dnscrypt-proxy.key.dnscrypt.info.

CNAME

A canonical name record, which says that one name is an alias for another. Content delivery networks use CNAMEs heavily, so the name you visit often points at a hostname owned by someone else. dnscrypt-proxy applies name blocklists to these aliases too, while cloaking flattens CNAME chains into plain addresses.

NXDOMAIN

The response code meaning “this name does not exist”, called Name Error in the original specification. A resolver that rewrites NXDOMAIN into an address, for example a search page, is lying about the answer. dnscrypt-proxy can log NXDOMAIN responses separately as suspicious queries, which makes typos and misconfigured software easy to spot.

EDNS(0)

The extension mechanisms for DNS defined in RFC 6891. EDNS lets a client and server signal larger message sizes and attach options to a query, for example padding or client subnet information. The version number is zero, hence the common spelling EDNS0. Without EDNS, DNSSEC answers would rarely fit into classic size limits.

EDNS Client Subnet (ECS)

An EDNS option from RFC 7871 that passes part of the client’s IP address to authoritative servers so they can return nearby servers. Its own privacy note recommends keeping it off by default. dnscrypt-proxy only adds subnet information when you set edns_client_subnet, and the example configuration leaves it commented out.

Padding

Extra bytes added to a message so that its length reveals less about its content. RFC 7830 defines an EDNS padding option for TLS-based transports. DNSCrypt pads every query and response itself, using ISO/IEC 7816-4 padding: one 0x80 byte followed by zeros, with responses usually rounded to a multiple of 64 bytes.

DNS glossary: DNSCrypt and dnscrypt-proxy

DNS stamp

A single sdns:// string that encodes everything a client needs to reach a server: protocol, properties, address, and either a DNSCrypt provider key or certificate hashes for DoH and DoT. The first byte names the protocol, for example 0x01 for DNSCrypt and 0x02 for DoH. The developer page shows the full layout.

Provider name

The name under which a DNSCrypt resolver publishes its certificates, in the form 2.dnscrypt-cert.example.com. The leading 2 is the major protocol version. The zone must be a valid DNS name but does not have to be registered. One provider name can serve several resolver addresses run by the same operator.

Provider public key

The 32-byte Ed25519 key that anchors trust in a DNSCrypt resolver. The client receives it out of band, usually inside a DNS stamp, and checks every certificate’s signature against it. It replaces the certificate authority used by DoH and DoT: whoever controls the matching secret key controls the resolver’s identity.

Certificate (DNSCrypt)

A small signed record, 124 bytes for the classical encryption system, that carries the resolver’s short-term public key, a serial number and a validity window. Clients fetch certificates over plain DNS, verify the Ed25519 signature, keep the highest valid serial, and refresh them regularly. Short-term keys let resolvers rotate without changing the stamp.

Cloaking

A dnscrypt-proxy feature that answers chosen names with your own addresses, like a hosts file that understands patterns. A rule such as example.com 192.168.2.37 covers the domain and its subdomains, and a name can point to another name, for example to force SafeSearch. Rules live in the file named by cloaking_rules.

Forwarding rules

Rules that send queries for selected domains to specific servers as plain DNS, outside the encrypted path. Typical uses are a local domain served by your router or an internal company zone. The file named by forwarding_rules maps a domain to one or more addresses, and the 2.1.6 release added $DHCP and $BOOTSTRAP keywords.

Blocklist and allow list

The two halves of DNS filtering in dnscrypt-proxy. A blocklist, in the [blocked_names] section, answers matching queries locally, with an HINFO record by default, before they leave your machine. An allow list, in [allowed_names], lets a name through even when a blocklist rule would catch it. Both lists use the same pattern syntax and can log matches.

Captive portal

A login page on hotel, airport or café Wi-Fi that intercepts traffic until you accept terms. Operating systems detect portals by resolving specific test names, which can fail while dnscrypt-proxy starts. The [captive_portals] section answers those test names instantly with hard-coded responses, so the operating system can show the login page.

DNS glossary: attacks and privacy

DNS spoofing

Any attack in which a forged DNS answer is accepted as genuine, so you connect to the attacker’s server under a familiar name. On plain DNS, an attacker on the network can read the query and reply first. Encrypted transports and DNSSEC validation each block part of it; the DNS spoofing page explains both.

Cache poisoning

A spoofing attack aimed at a shared resolver: a forged record lands in its cache and reaches every user until the TTL expires. The technique Dan Kaminsky published in 2008 made it far more practical. Source-port randomisation (RFC 5452), DNS Cookies (RFC 7873) and DNSSEC validation are the defences that followed.

DNS hijacking

Redirecting queries to a resolver you did not choose, for example by changing a router’s DNS setting or through malware on a device. No packet needs to be forged, because the hijacked resolver is the one answering. Encrypted DNS with server authentication defeats network-level hijacking, since an impostor cannot prove the configured identity.

DNS leak

A situation in which some queries bypass the resolver you configured, typically because an application or a second network interface still uses the network’s default resolver. The result is that a party you meant to avoid sees part of your browsing. The DNS leak check lists commands to see which resolver actually answers.

DNS rebinding

An attack in which a public name suddenly resolves to a private address, letting a malicious web page reach devices on your local network. dnscrypt-proxy can block it with IP rules: listing ranges such as 127.0.0.0/8, 10.0.0.0/8 and 192.168.0.0/16 in the IP blocklist drops public answers that point into them.

Using this DNS glossary

When a guide or configuration file uses one of these DNS terms, look it up here, then follow the link to the page that covers it in depth. Most readers continue with the protocol comparison, which uses the same vocabulary, or set up dnscrypt-proxy and meet the settings in its configuration file directly.