@@ -37,9 +37,10 @@ The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic betwee
 
 # Introduction
 
-The Domain Name System (DNS) {{!RFC1035}} is a critical component of Internet infrastructure, but its original design did not include security features to protect the confidentiality and integrity of queries and responses. This fundamental security gap exposes DNS traffic to eavesdropping, tampering, and various attacks that can compromise user privacy and network security.
-
-To address these vulnerabilities, this document defines the DNSCrypt protocol, which encrypts and authenticates DNS queries and responses, providing strong confidentiality, integrity, and resistance to attacks affecting the original DNS protocol. The protocol is designed to be lightweight, extensible, and simple to implement securely on top of existing DNS infrastructure, offering a practical solution for securing DNS communications without requiring significant changes to current systems.
+DNSCrypt encrypts and authenticates DNS traffic between clients and resolvers.
+It uses signed resolver certificates, unauthenticated certificate retrieval,
+authenticated encryption for queries and responses, and optional relaying
+through Anonymized DNSCrypt.
 
 # Conventions And Definitions
 
@@ -179,18 +180,18 @@ The protocol operates as follows:
 
 1. The DNSCrypt client sends a DNS query to a DNSCrypt server to retrieve the server's certificates.
 2. The client generates the client key-exchange value required by the selected certificate.
-3. The client encrypts unmodified DNS queries using the selected certificate, padding them as necessary, and concatenates them to `<client-magic>`, `<client-pk>`, and `<client-nonce>`. The resulting output is transmitted to the server via standard DNS transport mechanisms {{!RFC1035}}.
+3. The client encrypts unmodified DNS queries using the selected certificate, padding them as necessary, and concatenates them to `<client-magic>`, `<client-pk>`, and `<client-nonce>`. The resulting output is transmitted to the server over UDP or TCP.
 4. Encrypted queries are decrypted by the server using the query's `<client-pk>` field and the resolver secret key corresponding to the selected certificate. The output is a regular DNS packet that doesn't require any special processing.
-5. To send an encrypted response, the server adds padding to the unmodified response, encrypts the result using the shared key and a nonce made of the client's nonce followed by the resolver's nonce, and truncates the response if necessary. The resulting packet, truncated or not, is sent to the client using standard DNS mechanisms.
+5. To send an encrypted response, the server adds padding to the unmodified response, encrypts the result using the shared key and a nonce made of the client's nonce followed by the resolver's nonce, and truncates the response if necessary. The resulting packet, truncated or not, is sent to the client over the same transport.
 6. The client authenticates and decrypts the response using the shared key and the nonce included in the response. If the response was truncated, the client MAY adjust internal parameters and retry over TCP {{!RFC7766}}. If not, the output is a regular DNS response that can be directly forwarded to applications and stub resolvers.
 
 Key features of the DNSCrypt protocol include:
 
-- Stateless operation: Every query can be processed independently from other queries, with no session identifiers required.
-- Flexible key management: Clients can replace their keys whenever they want, without extra interactions with servers.
-- Proxy support: DNSCrypt packets can securely be proxied without having to be decrypted, allowing client IP addresses to be hidden from resolvers ("Anonymized DNSCrypt").
-- Shared infrastructure: Recursive DNS servers can accept DNSCrypt queries on the same IP address and port used for regular DNS traffic.
-- Attack mitigation: DNSCrypt mitigates two common security vulnerabilities in regular DNS over UDP: amplification {{!RFC5358}} and fragmentation attacks.
+- Stateless operation: every query can be processed independently, with no session identifiers required.
+- Fresh client key-exchange values: clients can generate new key-exchange values as often as allowed by the selected encryption system, without extra interactions with resolvers.
+- Proxy support: DNSCrypt packets can be relayed without being decrypted, allowing client IP addresses to be hidden from resolvers with Anonymized DNSCrypt.
+- Shared infrastructure: recursive DNS servers can accept DNSCrypt queries on the same IP address and port used for ordinary DNS traffic.
+- Attack mitigation: DNSCrypt limits UDP response size, supports padding, and uses TCP retry to reduce amplification and fragmentation risk {{!RFC5358}}.
 
 ## Transport
 
@@ -199,8 +200,6 @@ DNSCrypt clients and resolvers SHOULD support the protocol via UDP, and MUST sup
 
 Both TCP and UDP connections using DNSCrypt SHOULD employ port 443 by default.
 
-The choice of port 443 helps DNSCrypt traffic blend with HTTPS traffic, providing some protection against traffic analysis.
-
 ## DNS Wire Conventions Used Here
 
 Except where a cryptographic primitive explicitly says otherwise, all multi-byte
@@ -218,7 +217,7 @@ A DNS message starts with the 12-byte DNS header:
 
 The DNS flags field uses the ordinary DNS bit assignments. The bits used by
 this document are QR (`0x8000`), AA (`0x0400`), TC (`0x0200`), RD (`0x0100`),
-and RA (`0x0080`).
+RA (`0x0080`), and CD (`0x0010`).
 
 A DNS name in a query is encoded as a sequence of labels. Each label is one
 length octet, followed by that many bytes. The name ends with a zero length
@@ -245,6 +244,41 @@ character-string is a one-byte length followed by up to 255 bytes. A DNSCrypt
 certificate carried in a `TXT` record is reconstructed by concatenating those
 character-string payloads in order, excluding the one-byte length fields.
 
+A successful certificate response echoes the single question and contains zero
+or more `TXT` answer records, one certificate per answer record. A response that
+does not contain the complete certificate set because of a UDP size limit sets
+the DNS `TC` flag. A successful certificate response uses these DNS header
+fields:
+
+| Header field | Value                                           |
+| ------------ | ----------------------------------------------- |
+| ID           | copied from the query                           |
+| Flags        | QR set, TC set only when truncated, RCODE = 0   |
+| QDCOUNT      | 1                                               |
+| ANCOUNT      | number of certificate `TXT` answers included    |
+| NSCOUNT      | 0                                               |
+| ARCOUNT      | 0                                               |
+
+Resolvers MAY set ordinary DNS flags such as `AA` or `RA`, and MAY copy `RD`
+or `CD` from the query. Clients MUST ignore those flags for certificate
+validation. A client uses `TC` only to decide whether to retry the certificate
+query over TCP or with a larger padded UDP query.
+
+Each certificate answer is a `TXT` RR:
+
+| RR field | Value                                           |
+| -------- | ----------------------------------------------- |
+| NAME     | `0xc0 0x0c`, or the uncompressed question name  |
+| TYPE     | `TXT` (`0x00 0x10`)                             |
+| CLASS    | `IN` (`0x00 0x01`)                              |
+| TTL      | 4-byte DNS TTL; not the certificate validity    |
+| RDLENGTH | length in bytes of the TXT RDATA                |
+| RDATA    | certificate split into TXT character-strings    |
+
+The response does not echo the query's EDNS(0) `OPT` pseudo-RR. Certificate
+validity is determined only by `<ts-start>` and `<ts-end>` inside the signed
+certificate, not by the DNS TTL.
+
 When a UDP certificate query uses EDNS(0) padding, the additional record is an
 `OPT` pseudo-RR. It has root owner name (`0x00`), type `OPT` (`0x00 0x29`), a
 two-byte UDP payload size, four bytes of extended RCODE/version/flags, and an
@@ -290,7 +324,7 @@ source port.
 After receiving a query, a resolver MAY ignore it or send an encrypted DNSCrypt
 response.
 
-The client MUST authenticate and, if authentication succeeds, decrypt the response with the help of the resolver's public key, the shared secret, and the response nonce. The client MUST verify that the `<client-nonce>` prefix of the response nonce matches a currently outstanding query. In case the response fails verification, or the `<client-nonce>` does not match a currently outstanding query, it MUST be disregarded by the client.
+The client MUST authenticate and, if authentication succeeds, decrypt the response using the derived shared key and the response nonce. The client MUST verify that the `<client-nonce>` prefix of the response nonce matches a currently outstanding query. In case the response fails verification, or the `<client-nonce>` does not match a currently outstanding query, it MUST be disregarded by the client.
 
 If the response has the TC flag set, the client MUST:
 
@@ -403,7 +437,7 @@ The following diagram shows the structure of a DNSCrypt certificate:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
-To initiate a DNSCrypt session, a client transmits an ordinary unencrypted `TXT` DNS query to the resolver's IP address and DNSCrypt port. A client MAY use UDP or TCP according to local policy. A common strategy is to try UDP first and retry over TCP after failure, timeout, or truncation.
+To initiate a DNSCrypt session, a client transmits an ordinary unencrypted `TXT` DNS query to the resolver's IP address and DNSCrypt port. A client MAY use UDP or TCP according to local policy. A common strategy is to try UDP first and retry over TCP after failure, timeout, or truncation. Over TCP, the certificate query and response are DNS messages framed with the two-byte big-endian DNS-over-TCP length prefix {{!RFC7766}}; the prefix is not part of the DNS message.
 
 Resolvers are not required to serve certificates both on UDP and TCP.
 
@@ -706,7 +740,7 @@ Relays MUST:
    - Check that the target IP is not in a private, loopback, link-local, multicast, unspecified, or otherwise locally routed range
    - Verify the port number is in an allowed range
    - Ensure the inner `<dnscrypt-query>` doesn't start with `<anon-magic>`
-   - Reject the inner `<dnscrypt-query>` if its first 8 bytes are `0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01`, to avoid protocol confusion with QUIC {{!RFC9000}}; relays MAY reject broader reserved prefixes by local policy
+   - Reject the inner `<dnscrypt-query>` if its first 8 bytes are `0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01`, to avoid protocol confusion with QUIC {{!RFC9000}}
 4. Forward the inner `<dnscrypt-query>` unmodified to the target server over UDP, without the Anonymized DNSCrypt prefix
 5. Verify server responses:
 
@@ -717,7 +751,49 @@ Relays MUST:
 
 Address validation is performed after decoding `<server-ip>`. If the decoded address is an IPv4-mapped IPv6 address, the relay applies the IPv4 policy to the embedded IPv4 address. Relay operators SHOULD maintain an explicit allowlist or denylist of target ranges. At minimum, relays MUST reject targets that are not globally routable, including unspecified, loopback, link-local, multicast, private-use, unique-local, documentation, benchmarking, and other special-use addresses.
 
-These relay requirements ensure that anonymization does not compromise the security properties of the underlying DNSCrypt protocol. Proper deployment requires additional operational considerations.
+If relay validation fails, the relay MUST NOT forward the inner packet. For a
+UDP client, the relay sends no response. For a TCP client, the relay closes the
+connection without sending a length-prefixed response. The same behavior applies
+to upstream responses that fail validation or exceed the response-size rule.
+
+The mandatory QUIC-confusion check above is intentionally the exact 8-byte
+value. The broader rule that `<client-magic>` MUST NOT start with seven zero
+bytes is enforced when resolvers issue certificates. A relay cannot classify
+every inner packet by the first eight bytes alone, because the inner packet can
+also be an unencrypted certificate query. Relay operators MAY reject broader
+reserved prefixes by local policy after first recognizing valid certificate
+queries.
+
+A relay recognizes an inner certificate query by parsing it as a DNS message
+with `QR = 0`, `QDCOUNT = 1`, question type `TXT`, question class `IN`, and a
+question name that starts with `2.dnscrypt-cert.`. Relays are not required to
+support non-standard provider names through Anonymized DNSCrypt; clients using
+such names can retrieve certificates directly from the resolver.
+
+An encrypted upstream response is valid for relaying if all of these are true:
+
+- The response came from the target IP address and port selected by the prefix.
+- The response is no larger than the inner query forwarded upstream.
+- The response starts with `<resolver-magic>`.
+
+No stronger encrypted-response matching is required at the relay. The relay
+does not decrypt the packet, does not know the selected certificate, and cannot
+in general know the offset of `<client-nonce>` because the `<client-pk>` length
+depends on the encryption system and resumed PQ queries use a different shape.
+The client performs nonce matching after decryption.
+
+A certificate upstream response is valid for relaying if all of these are true:
+
+- The response came from the target IP address and port selected by the prefix.
+- The response is no larger than the inner certificate query forwarded upstream.
+- The response is a DNS response (`QR = 1`) and has the same transaction ID as
+  the relayed certificate query.
+- The response contains exactly one question whose name, type, and class match
+  the relayed certificate query.
+- The matching question name starts with `2.dnscrypt-cert.`.
+
+The relay does not need to validate certificate signatures or parse every TXT
+answer. The client verifies certificates after receiving the relayed response.
 
 ## Operational Considerations
 
@@ -730,11 +806,9 @@ When using Anonymized DNSCrypt:
    - Restrict allowed server ports (typically only allowing port 443)
    - Monitor for abuse
 
-These operational guidelines help ensure that Anonymized DNSCrypt deployments provide the intended privacy benefits while maintaining security and preventing abuse.
-
 # Post-Quantum Key Exchange (PQDNSCrypt)
 
-The key exchange described so far relies on X25519 {{!RFC7748}}, which a sufficiently capable quantum computer would be able to break. An attacker who records DNSCrypt traffic today could therefore decrypt it once such a computer exists. This section defines the PQ extension, which performs the key exchange with a hybrid post-quantum mechanism while leaving the rest of the protocol unchanged: the certificate system, the packet framing, the authenticated encryption, the nonces, the padding philosophy, and Anonymized DNSCrypt all carry over. A DNSCrypt deployment that uses this extension is referred to as PQDNSCrypt.
+The classical `Box-XChaChaPoly` encryption system relies on X25519 {{!RFC7748}}, which a sufficiently capable quantum computer would be able to break. An attacker who records classical DNSCrypt traffic today could therefore decrypt it once such a computer exists. This section defines the PQ extension, which performs the key exchange with a hybrid post-quantum mechanism while leaving the rest of the protocol unchanged: the certificate system, the packet framing, the authenticated encryption, the nonces, the padding philosophy, and Anonymized DNSCrypt all carry over. A DNSCrypt deployment that uses this extension is referred to as PQDNSCrypt.
 
 PQ is introduced as a new encryption system version (`<es-version>` `0x00 0x03`) inside the existing version 2 certificate format. It is not a new major protocol version, and it does not change the certificate lookup name. A resolver MAY advertise a PQ certificate alongside a classical certificate under the same provider name, and a client that does not implement PQ ignores the `<es-version>` value it does not recognize, exactly as already required.
 
@@ -1185,7 +1259,7 @@ The successful response carrying the 124-byte certificate above is 182 bytes. Th
 
 ~~~
 certificate response with one TXT answer (182 bytes):
-  abcd8481000100010000000001320d646e7363727970742d6365727407657861
+  abcd8180000100010000000001320d646e7363727970742d6365727407657861
   6d706c6503636f6d0000100001c00c0010000100015180007d7c444e53430002
   00003a570ea17f47b80217977fbb455840bfd50ab32f5fbf2aabc173a6a49b7a
   49ca55362a6c5dec47657cf515e9f99382a316dfecd964b94d1c4659cac45961