[PR #2179] [MERGED] resolver: err for dns-over-rustls w/o roots #2861

New issue

Closed

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

kerem commented

2026-03-16 11:12:15 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/2179
Author: @cpu
Created: 4/13/2024
Status: ✅ Merged
Merged: 4/14/2024
Merged by: @djc

Base: main ← Head: cpu-err-no-rustls-roots

📝 Commits (1)

cf30a1e resolver: err for dns-over-rustls w/o roots

📊 Changes

2 files changed (+16 additions, -0 deletions)

View changed files

📝 crates/resolver/src/name_server/name_server_pool.rs (+6 -0)
📝 crates/resolver/src/tls/dns_over_rustls.rs (+10 -0)

📄 Description

If we're setting up dns-over-rustls and find that we've constructed a Rustls root cert store that has no trust anchors, return an early error. This makes the problem obvious and avoids surfacing some other less specific error cause when we first try to validate a peer certificate with an empty root store.

In order for our new early error to be surfaced correctly the name_sever_pool.rs parallel_conn_loop fn needs its error handling adjusted. Previously it would always compare the new error produced by trying to build the TLS config against the default error it starts its loop with, ProtoErrorKind::NoConnections. Since the error being returned is another ProtoErrorKind that isn't NoRecordsFound, Io, or Timeout the error specificity comparison considers the two errors equivalent in the general case, and the default error was always returned and the new error thrown away.

There is still a small mystery around why a more specific error from tokio-rustls isn't returned when peer validation inevitably fails. In my testing upstream we get a nice io::Error like err: Custom { kind: InvalidData, error: InvalidCertificate(UnknownIssuer) }. I can't figure out where or why, but something in the Hickory DNS stack is reducing this down to just a simple io error with type InvalidData - no nested source error or message. See my comment here I think this is a side-effect of the Clone impl on ProtoErrorKind.

Updates https://github.com/hickory-dns/hickory-dns/issues/2066

_{🔄 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/2179 **Author:** [@cpu](https://github.com/cpu) **Created:** 4/13/2024 **Status:** ✅ Merged **Merged:** 4/14/2024 **Merged by:** [@djc](https://github.com/djc) **Base:** `main` ← **Head:** `cpu-err-no-rustls-roots` --- ### 📝 Commits (1) - [`cf30a1e`](https://github.com/hickory-dns/hickory-dns/commit/cf30a1e9c6076184364476631e196cbf8c0cb0ba) resolver: err for dns-over-rustls w/o roots ### 📊 Changes **2 files changed** (+16 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `crates/resolver/src/name_server/name_server_pool.rs` (+6 -0) 📝 `crates/resolver/src/tls/dns_over_rustls.rs` (+10 -0) </details> ### 📄 Description If we're setting up dns-over-rustls and find that we've constructed a Rustls root cert store that has no trust anchors, return an early error. This makes the problem obvious and avoids surfacing some other less specific error cause when we first try to validate a peer certificate with an empty root store. In order for our new early error to be surfaced correctly the `name_sever_pool.rs` [`parallel_conn_loop` fn](https://github.com/hickory-dns/hickory-dns/blob/6c2a1e2c238eaecff2b6b6c1c0e435685bc0997e/crates/resolver/src/name_server/name_server_pool.rs#L304-L392) needs its error handling adjusted. Previously it would always compare the new error produced by trying to build the TLS config against [the default error](https://github.com/hickory-dns/hickory-dns/blob/6c2a1e2c238eaecff2b6b6c1c0e435685bc0997e/crates/resolver/src/name_server/name_server_pool.rs#L312) it starts its loop with, `ProtoErrorKind::NoConnections`. Since the error being returned is another `ProtoErrorKind` that isn't `NoRecordsFound`, `Io`, or `Timeout` the error specificity comparison considers the two errors equivalent [in the general case](https://github.com/hickory-dns/hickory-dns/blob/6c2a1e2c238eaecff2b6b6c1c0e435685bc0997e/crates/proto/src/error.rs#L487), and the default error was always returned and the new error thrown away. ~There is still a small mystery around why a more specific error from tokio-rustls isn't returned when peer validation inevitably fails. In my testing upstream we get a nice `io::Error` like `err: Custom { kind: InvalidData, error: InvalidCertificate(UnknownIssuer) }`. I can't figure out where or why, but something in the Hickory DNS stack is reducing this down to just a simple io error with type `InvalidData` - no nested source error or message.~ See [my comment here](https://github.com/hickory-dns/hickory-dns/issues/2066#issuecomment-2053743003) I think this is a side-effect of the `Clone` impl on `ProtoErrorKind`. Updates https://github.com/hickory-dns/hickory-dns/issues/2066 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>