You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f8b38ed
Browse filesBrowse the repository at this point in the historyBrowse files
<pid="section-3-6.3.1">The client detects a certificate with a higher serial number<ahref="#section-3-6.3.1" class="pilcrow">¶</a></p>
1457
+
<liclass="normal" id="section-3-4.3">
1458
+
<pid="section-3-4.3.1">The client detects a certificate with a higher serial number<ahref="#section-3-4.3.1" class="pilcrow">¶</a></p>
1483
1459
</li>
1484
1460
</ul>
1485
-
<pid="section-3-7">After the initial setup, the client and server engage in the ongoing communication phase (steps 3-8), where encrypted queries and responses are exchanged as needed. This phase can be repeated indefinitely until the certificate expires or a new certificate is available.<ahref="#section-3-7" class="pilcrow">¶</a></p>
1486
-
<pid="section-3-8">The ongoing communication phase operates with several important characteristics that distinguish it from traditional DNS:<ahref="#section-3-8" class="pilcrow">¶</a></p>
<pid="section-3-9.1.1"><strong>Stateless Operation</strong>: Each query and response is independent. The server does not maintain state between queries.<ahref="#section-3-9.1.1" class="pilcrow">¶</a></p>
1461
+
<pid="section-3-5">After selecting a certificate, every encrypted query and response is
<pid="section-3-6.1.1"><strong>Stateless Operation</strong>: Each query and response is independent. The server does not maintain state between queries.<ahref="#section-3-6.1.1" class="pilcrow">¶</a></p>
1490
1466
</li>
1491
-
<liid="section-3-9.2">
1492
-
<pid="section-3-9.2.1"><strong>Out-of-Order Responses</strong>: Responses may arrive in a different order than the queries were sent. Each response is self-contained and can be processed independently.<ahref="#section-3-9.2.1" class="pilcrow">¶</a></p>
1467
+
<liid="section-3-6.2">
1468
+
<pid="section-3-6.2.1"><strong>Out-of-Order Responses</strong>: Responses may arrive in a different order than the queries were sent. Each response is self-contained and can be processed independently.<ahref="#section-3-6.2.1" class="pilcrow">¶</a></p>
1493
1469
</li>
1494
-
<liid="section-3-9.3">
1495
-
<pid="section-3-9.3.1"><strong>Concurrent Queries</strong>: A client can send multiple queries without waiting for earlier responses, and responses can be processed independently as they arrive.<ahref="#section-3-9.3.1" class="pilcrow">¶</a></p>
1470
+
<liid="section-3-6.3">
1471
+
<pid="section-3-6.3.1"><strong>Concurrent Queries</strong>: A client can send multiple queries without waiting for earlier responses, and responses can be processed independently as they arrive.<ahref="#section-3-6.3.1" class="pilcrow">¶</a></p>
<pid="section-5.4-1">From the client's perspective, a DNSCrypt session is initiated when the client sends an unauthenticated DNS query to a DNSCrypt-capable resolver. This DNS query contains the major protocol version and a public identifier of the desired provider.<ahref="#section-5.4-1" class="pilcrow">¶</a></p>
1756
-
<pid="section-5.4-2">The resolver sends back a collection of signed certificates that the client <spanclass="bcp14">MUST</span> verify using the pre-distributed provider public key. Each certificate includes a validity period, a serial number, a version that defines a keyexchange mechanism, an authenticatedencryption algorithm and its parameters, as well as a short-term public key, known as the resolver public key.<ahref="#section-5.4-2" class="pilcrow">¶</a></p>
1757
-
<pid="section-5.4-3">Resolvers have the ability to support various algorithms and can concurrently advertise multiple short-term public keys (resolver public keys). The client selects one of the currently valid certificates according to the certificate selection rules below.<ahref="#section-5.4-3" class="pilcrow">¶</a></p>
1732
+
<pid="section-5.4-2">The resolver sends back a collection of signed certificates that the client <spanclass="bcp14">MUST</span> verify using the pre-distributed provider public key. Each certificate includes a validity period, a serial number, a version that defines the key-exchange and authenticated-encryption system, and the resolver key-exchange public field for that system.<ahref="#section-5.4-2" class="pilcrow">¶</a></p>
1733
+
<pid="section-5.4-3">Resolvers can concurrently advertise multiple encryption systems and multiple short-term resolver key-exchange public fields. The client selects one of the currently valid certificates according to the certificate selection rules below.<ahref="#section-5.4-3" class="pilcrow">¶</a></p>
1758
1734
<pid="section-5.4-4">Every certificate contains a unique magic number that the client <spanclass="bcp14">MUST</span> include at the beginning of their queries. This allows the resolver to identify which certificate the client selected for crafting a particular query.<ahref="#section-5.4-4" class="pilcrow">¶</a></p>
1759
-
<pid="section-5.4-5">The encryption algorithm, resolver public key, and client magic number from the chosen certificate are then used by the client to send encrypted queries. These queries include the <code><client-pk></code> key-exchange field.<ahref="#section-5.4-5" class="pilcrow">¶</a></p>
1735
+
<pid="section-5.4-5">The encryption system, resolver key-exchange public field, and client magic number from the chosen certificate are then used by the client to send encrypted queries. These queries include the <code><client-pk></code> key-exchange field.<ahref="#section-5.4-5" class="pilcrow">¶</a></p>
1760
1736
<pid="section-5.4-6">With the chosen certificate, the corresponding resolver secret key, and the query's <code><client-pk></code> field, the resolver is able to verify and decrypt the query, then encrypt the response with the same parameters.<ahref="#section-5.4-6" class="pilcrow">¶</a></p>
1761
-
<pid="section-5.4-7">Once the session is established through certificate exchange, the ongoing query processing follows specific rules for different transport protocols and padding requirements.<ahref="#section-5.4-7" class="pilcrow">¶</a></p>
<pid="section-5.5.7-1">The resolver <spanclass="bcp14">MUST</span> authenticate and decrypt client queries as described for UDP. Queries that cannot be authenticated, decrypted, unpadded, or parsed as DNS messages <spanclass="bcp14">MUST</span> be ignored.<ahref="#section-5.5.7-1" class="pilcrow">¶</a></p>
1874
1849
<pid="section-5.5.7-2">Responses sent over TCP <spanclass="bcp14">MUST</span> be padded as described in "Padding For Resolver Responses" and encrypted as <code><dnscrypt-response></code>. The complete encrypted response packet is then prefixed with a two-byte big-endian length.<ahref="#section-5.5.7-2" class="pilcrow">¶</a></p>
1875
1850
<pid="section-5.5.7-3">Cleartext DNS response payloads are not prefixed by their length before encryption, even when the DNSCrypt packet is sent over TCP. Unlike UDP responses, TCP responses <spanclass="bcp14">MUST</span> be sent unmodified even if their encrypted length exceeds the encrypted query length.<ahref="#section-5.5.7-3" class="pilcrow">¶</a></p>
1876
-
<pid="section-5.5.7-4">The query and response processing rules described above depend on the certificate information obtained during session establishment. The certificate format and management procedures are critical to the protocol's security.<ahref="#section-5.5.7-4" class="pilcrow">¶</a></p>
<pid="section-7-1"><em>Note: This section is to be removed before publishing as an RFC.</em><ahref="#section-7-1" class="pilcrow">¶</a></p>
2093
2067
<pid="section-7-2">Multiple implementations of the protocol described in this document have been developed and verified for interoperability. A comprehensive list of known implementations can be found at <ahref="https://dnscrypt.info/implementations">dnscrypt.info implementations</a>.<ahref="#section-7-2" class="pilcrow">¶</a></p>
2094
-
<pid="section-7-3">The successful deployment of multiple interoperable implementations demonstrates the protocol's maturity. However, proper implementation requires careful attention to security considerations.<ahref="#section-7-3" class="pilcrow">¶</a></p>
<pid="section-8.3-2.4.1"><strong>Replay Exposure Reduction</strong>: Nonces make responses query-specific. Clients can discard late, duplicate, or unrelated responses by checking the returned <code><client-nonce></code> against local outstanding-query state and request deadlines, without exposing timestamps in plaintext nonce values.<ahref="#section-8.3-2.4.1" class="pilcrow">¶</a></p>
2221
2193
</li>
2222
2194
</ol>
2223
-
<pid="section-8.3-3">While DNSCrypt effectively mitigates these attacks, implementers should also be aware of privacy considerations that extend beyond basic protocol security.<ahref="#section-8.3-3" class="pilcrow">¶</a></p>
<pid="section-8.4-2.4.1"><strong>Certificate Requests</strong>: Initial certificate requests are unencrypted but only return public data. This is a one-time exposure per session.<ahref="#section-8.4-2.4.1" class="pilcrow">¶</a></p>
2244
2215
</li>
2245
2216
</ol>
2246
-
<pid="section-8.4-3">These privacy considerations complement the security measures and should inform operational practices for DNSCrypt deployments.<ahref="#section-8.4-3" class="pilcrow">¶</a></p>
<pid="section-8.5-3">These operational security practices work together with the technical security measures to provide comprehensive protection. Additional operational considerations extend beyond security to include practical deployment aspects.<ahref="#section-8.5-3" class="pilcrow">¶</a></p>
<pid="section-9-5">Resolvers <spanclass="bcp14">MUST</span> rotate each short-term key pair every 24 hours at most. After a key rotation, a resolver <spanclass="bcp14">MUST</span> continue accepting queries for every unexpired certificate it still serves, which requires retaining the corresponding resolver secret keys. Once all certificates for an old resolver key have expired or been withdrawn, the resolver <spanclass="bcp14">MUST</span> discard that old secret key. If an old resolver key is believed to be compromised, the resolver <spanclass="bcp14">MUST</span> withdraw the related certificates and discard the key instead of continuing to accept it.<ahref="#section-9-5" class="pilcrow">¶</a></p>
2328
2297
<pid="section-9-6">Provider public keys <spanclass="bcp14">MAY</span> be published as DNSSEC-signed <code>TXT</code> records <span>[<ahref="#RFC1035" class="cite xref">RFC1035</a>]</span>, in the same zone as the provider name. For example, a query for the <code>TXT</code> type on the name <code>"2.pubkey.example.com"</code> may return a signed record containing a hexadecimal-encoded provider public key for the provider name <code>"2.dnscrypt-cert.example.com"</code>.<ahref="#section-9-6" class="pilcrow">¶</a></p>
2329
2298
<pid="section-9-7">For encryption systems where clients reuse a key pair, servers are encouraged to cache shared keys instead of performing the X25519 operation for each query. This makes the computational overhead of classical DNSCrypt negligible compared to plain DNS.<ahref="#section-9-7" class="pilcrow">¶</a></p>
2330
-
<pid="section-9-8">While DNSCrypt provides strong encryption and authentication, some use cases require additional privacy protection. The Anonymized DNSCrypt extension addresses scenarios where hiding client IP addresses from resolvers is necessary.<ahref="#section-9-8" class="pilcrow">¶</a></p>
<pid="section-10-1">While DNSCrypt encrypts DNS traffic, DNS server operators can still observe client IP addresses. Anonymized DNSCrypt is an extension to the DNSCrypt protocol that allows queries and responses to be relayed by an intermediate server, hiding the client's IP address from the resolver.<ahref="#section-10-1" class="pilcrow">¶</a></p>
2339
-
<pid="section-10-2">This extension maintains all the security properties of standard DNSCrypt while adding an additional layer of privacy protection.<ahref="#section-10-2" class="pilcrow">¶</a></p>
0 commit comments