[PR #3276] [MERGED] Implement RFC 9539 opportunistic encryption for recursive resolver #3701

New issue

Closed

opened 2026-03-16 11:58:03 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 11:58:03 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/3276
Author: @cpu
Created: 9/22/2025
Status: ✅ Merged
Merged: 10/16/2025
Merged by: @cpu

Base: main ← Head: cpu-9539_dev

📝 Commits (6)

6ae7350 resolver: allow skipping TLS peer verification
0d79600 start modelling opportunistic encryption config
2bd9a74 start tracking opportunistic enc. transport state
b8f2289 resolver: offer access to ConnectionProvider::RuntimeProvider
5039a9a implement opportunistic encryption probing
5f831c5 conformance: add hickory resolver rfc 9539 tests

📊 Changes

17 files changed (+2086 additions, -58 deletions)

View changed files

📝 bin/src/lib.rs (+9 -0)
📝 bin/tests/integration/config_tests.rs (+8 -0)
📝 conformance/dns-test/src/tshark.rs (+34 -9)
📝 conformance/e2e-tests/src/recursor.rs (+1 -0)
➕ conformance/e2e-tests/src/recursor/rfc9539.rs (+1 -0)
➕ conformance/e2e-tests/src/recursor/rfc9539/scenarios.rs (+267 -0)
📝 crates/recursor/src/recursor.rs (+27 -1)
📝 crates/recursor/src/recursor_dns_handle.rs (+47 -8)
📝 crates/resolver/src/config.rs (+344 -2)
📝 crates/resolver/src/name_server/connection_provider.rs (+98 -2)
📝 crates/resolver/src/name_server/name_server.rs (+1020 -23)
📝 crates/resolver/src/name_server/name_server_pool.rs (+38 -6)
📝 crates/resolver/src/resolver.rs (+41 -2)
📝 crates/server/src/store/recursor.rs (+34 -1)
📝 tests/integration-tests/src/mock_client.rs (+4 -0)
📝 tests/integration-tests/tests/integration/name_server_pool_tests.rs (+16 -4)
➕ tests/test-data/test_configs/example_recursor_opportunistic_enc.toml (+97 -0)

📄 Description

If we prefer opportunistic encryption and are evaluating pre-existing name server connections, prefer encrypted ones first. If we only have unencrypted pre-existing connections, but we've registered a recent successful probe on an encrypted protocol, don't reuse the conn at all. Instead make a new conn using the successfully probed encrypted protocol.

When sorting connection configs to make a new connection, and using opportunistic encryption, consider whether we've had a successful response read from an encrypted connection to the name server within the persistence period. If so, prefer those configs to make new encrypted connections with the same protocol.

Lastly, when opportunistic encryption is enabled, and we select a non-encrypted connection config (e.g. because we don't have a pre-existing encrypted conn, or because we don't have a successful response recorded on an encrypted transport within the persistence period) and we haven't recorded a failure within the damping period, then try to probe the name server on an encrypted protocol. Use the result to update the name server encrypted transport state so that the next time we'll know whether to jump straight to an encrypted transport, or if we should continue to use the unencrypted transport. Constrain the number of extant probes based on a configurable budget.

Follow-up items out of scope for this first PR:

Metrics - they'd be nice to have :-)
authoritative server encrypted transport connection state persistence/reloading. RFC 9539 marks some state as to be persisted across reboots. I've tried to lay some groundwork for this but haven't implemented it yet for hickory-dns. It would be nice to sort out so that a reboot doesn't cause the resolver to have to re-discover the world with fresh probes.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/3276 **Author:** [@cpu](https://github.com/cpu) **Created:** 9/22/2025 **Status:** ✅ Merged **Merged:** 10/16/2025 **Merged by:** [@cpu](https://github.com/cpu) **Base:** `main` ← **Head:** `cpu-9539_dev` --- ### 📝 Commits (6) - [`6ae7350`](https://github.com/hickory-dns/hickory-dns/commit/6ae7350acfa55fcd044e472704aac391bdd89721) resolver: allow skipping TLS peer verification - [`0d79600`](https://github.com/hickory-dns/hickory-dns/commit/0d7960060950f55cdc9abeb01c5e3b3f5c3e0d6b) start modelling opportunistic encryption config - [`2bd9a74`](https://github.com/hickory-dns/hickory-dns/commit/2bd9a74132117b581313e7cd584b3aa0dcd9675c) start tracking opportunistic enc. transport state - [`b8f2289`](https://github.com/hickory-dns/hickory-dns/commit/b8f2289b8e2c28c03bab824f9665b184354b18fa) resolver: offer access to ConnectionProvider::RuntimeProvider - [`5039a9a`](https://github.com/hickory-dns/hickory-dns/commit/5039a9a10606bbefba6b5d78b969dbf9abca693d) implement opportunistic encryption probing - [`5f831c5`](https://github.com/hickory-dns/hickory-dns/commit/5f831c5aa68b860c7e9e5fa1894c0e57da51f64f) conformance: add hickory resolver rfc 9539 tests ### 📊 Changes **17 files changed** (+2086 additions, -58 deletions) <details> <summary>View changed files</summary> 📝 `bin/src/lib.rs` (+9 -0) 📝 `bin/tests/integration/config_tests.rs` (+8 -0) 📝 `conformance/dns-test/src/tshark.rs` (+34 -9) 📝 `conformance/e2e-tests/src/recursor.rs` (+1 -0) ➕ `conformance/e2e-tests/src/recursor/rfc9539.rs` (+1 -0) ➕ `conformance/e2e-tests/src/recursor/rfc9539/scenarios.rs` (+267 -0) 📝 `crates/recursor/src/recursor.rs` (+27 -1) 📝 `crates/recursor/src/recursor_dns_handle.rs` (+47 -8) 📝 `crates/resolver/src/config.rs` (+344 -2) 📝 `crates/resolver/src/name_server/connection_provider.rs` (+98 -2) 📝 `crates/resolver/src/name_server/name_server.rs` (+1020 -23) 📝 `crates/resolver/src/name_server/name_server_pool.rs` (+38 -6) 📝 `crates/resolver/src/resolver.rs` (+41 -2) 📝 `crates/server/src/store/recursor.rs` (+34 -1) 📝 `tests/integration-tests/src/mock_client.rs` (+4 -0) 📝 `tests/integration-tests/tests/integration/name_server_pool_tests.rs` (+16 -4) ➕ `tests/test-data/test_configs/example_recursor_opportunistic_enc.toml` (+97 -0) </details> ### 📄 Description If we prefer opportunistic encryption and are evaluating pre-existing name server connections, prefer encrypted ones first. If we only have unencrypted pre-existing connections, but we've registered a recent successful probe on an encrypted protocol, don't reuse the conn at all. Instead make a new conn using the successfully probed encrypted protocol. When sorting connection configs to make a new connection, and using opportunistic encryption, consider whether we've had a successful response read from an encrypted connection to the name server within the persistence period. If so, prefer those configs to make new encrypted connections with the same protocol. Lastly, when opportunistic encryption is enabled, and we select a non-encrypted connection config (e.g. because we don't have a pre-existing encrypted conn, or because we don't have a successful response recorded on an encrypted transport within the persistence period) _and_ we haven't recorded a failure within the damping period, then try to probe the name server on an encrypted protocol. Use the result to update the name server encrypted transport state so that the next time we'll know whether to jump straight to an encrypted transport, or if we should continue to use the unencrypted transport. Constrain the number of extant probes based on a configurable budget. Follow-up items out of scope for this first PR: * Metrics - they'd be nice to have :-) * authoritative server encrypted transport connection state persistence/reloading. RFC 9539 marks some state as to be persisted across reboots. I've tried to lay some groundwork for this but haven't implemented it yet for `hickory-dns`. It would be nice to sort out so that a reboot doesn't cause the resolver to have to re-discover the world with fresh probes. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>