[GH-ISSUE #1597] Breaking options change for HTTPS-only queries in 0.21 alpha #706

New issue

Closed

opened 2026-03-15 23:54:32 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:54:32 +03:00

Owner

Originally created by @ecton on GitHub (Dec 5, 2021).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1597

Describe the bug

If you are using a resolver with only an HTTPS configuration, you now need to specify try_tcp_on_error = true during configuration, otherwise you get a NoConnections error returned.

To Reproduce
Steps to reproduce the behavior:

let mut opts = ResolverOpts::default();
// ... configuration options
// opts.try_tcp_on_error = true; // This line is now required in the 0.21 alpha

// build the `Resolver`
let resolver = TokioAsyncResolver::tokio(ResolverConfig::cloudflare_https(), opts)
	.map_err(Box::new)?;
// query the IP
let ip = resolver.lookup_ip(domain.clone()).await?;

Expected behavior

I would expect a pure HTTPS configuration to not require a setting named try_tcp_on_error to be set. To me (a casual user of the library), I would expect with a single HTTPS nameserver configured, the query would be over TCP by default, and a "try on error" configuration wouldn't be necessary. The CHANGELOG entry did not seem to imply that it would impact this situation -- I had to open the pull request to try to understand what that entry actually meant.

The time I spent trying to figure out what change might have impacted me is what led me to filing this report. Even if no changes are made, someone else who encounters this might discover this report when searching.

Thank you for the excellent library!

Version:
Crate: resolver
Version: 0.21.0-alpha-4

Originally created by @ecton on GitHub (Dec 5, 2021). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1597 **Describe the bug** If you are using a resolver with only an HTTPS configuration, you now need to specify `try_tcp_on_error = true` during configuration, otherwise you get a `NoConnections` error returned. **To Reproduce** Steps to reproduce the behavior: ```rust let mut opts = ResolverOpts::default(); // ... configuration options // opts.try_tcp_on_error = true; // This line is now required in the 0.21 alpha // build the `Resolver` let resolver = TokioAsyncResolver::tokio(ResolverConfig::cloudflare_https(), opts) .map_err(Box::new)?; // query the IP let ip = resolver.lookup_ip(domain.clone()).await?; ``` **Expected behavior** I would expect a pure HTTPS configuration to not require a setting named `try_tcp_on_error` to be set. To me (a casual user of the library), I would expect with a single HTTPS nameserver configured, the query would be over TCP by default, and a "try on error" configuration wouldn't be necessary. The CHANGELOG entry did not seem to imply that it would impact this situation -- I had to open the pull request to try to understand what that entry actually meant. The time I spent trying to figure out what change might have impacted me is what led me to filing this report. Even if no changes are made, someone else who encounters this might discover this report when searching. Thank you for the excellent library! **Version:** Crate: resolver Version: 0.21.0-alpha-4