starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #2108] dns-over-tls with dns-over-rustls broken since 0.24 #887

New issue

Closed

opened 2026-03-16 00:45:23 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 00:45:23 +03:00

Owner

Originally created by @zonyitoo on GitHub (Dec 9, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2108

Describe the bug

hickory-resolver with dns-over-rustls is broken since 0.24.

To Reproduce

Dependency:

[dependencies]
hickory-resolver = { version = "0.24", features = [
    "dns-over-tls",
    "dns-over-rustls",
] }

Test code, borrowed from library's example:

use hickory_resolver::config::*;
use hickory_resolver::Resolver;
use std::net::*;

fn main() {
    env_logger::init();

    let resolver =
        Resolver::new(ResolverConfig::cloudflare_tls(), ResolverOpts::default()).unwrap();
    let response = resolver.lookup_ip("www.example.com.").unwrap();
    let address = response.iter().next().expect("no addresses returned!");
    if address.is_ipv4() {
        assert_eq!(address, IpAddr::V4(Ipv4Addr::new(93, 184, 216, 34)));
    } else {
        assert_eq!(
            address,
            IpAddr::V6(Ipv6Addr::new(
                0x2606, 0x2800, 0x220, 0x1, 0x248, 0x1893, 0x25c8, 0x1946
            ))
        );
    }
}

Expected behavior

resolver.lookup_ip("www.example.com") should be able to resolve, but returned error:

thread 'main' panicked at src/main.rs:10:59:
called `Result::unwrap()` on an `Err` value: ResolveError { kind: Proto(ProtoError { kind: Io(Kind(ConnectionRefused)) }) }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

System:

OS: macOS
Architecture: x86_64
Version 14.1.2
rustc version: rustc 1.74.0 (79e9716c9 2023-11-13)

Version:
Crate: resolver
Version: 0.24.0

Additional context

Detailed TRACE log: TRACE.log

Error doesn't exist if we are using dns-over-native-tls.

Ref: shadowsocks/shadowsocks-rust#1378

Originally created by @zonyitoo on GitHub (Dec 9, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2108 **Describe the bug** `hickory-resolver` with `dns-over-rustls` is broken since 0.24. **To Reproduce** Dependency: ```toml [dependencies] hickory-resolver = { version = "0.24", features = [ "dns-over-tls", "dns-over-rustls", ] } ``` Test code, borrowed from library's example: ```rust use hickory_resolver::config::*; use hickory_resolver::Resolver; use std::net::*; fn main() { env_logger::init(); let resolver = Resolver::new(ResolverConfig::cloudflare_tls(), ResolverOpts::default()).unwrap(); let response = resolver.lookup_ip("www.example.com.").unwrap(); let address = response.iter().next().expect("no addresses returned!"); if address.is_ipv4() { assert_eq!(address, IpAddr::V4(Ipv4Addr::new(93, 184, 216, 34))); } else { assert_eq!( address, IpAddr::V6(Ipv6Addr::new( 0x2606, 0x2800, 0x220, 0x1, 0x248, 0x1893, 0x25c8, 0x1946 )) ); } } ``` **Expected behavior** `resolver.lookup_ip("www.example.com")` should be able to resolve, but returned error: ``` thread 'main' panicked at src/main.rs:10:59: called `Result::unwrap()` on an `Err` value: ResolveError { kind: Proto(ProtoError { kind: Io(Kind(ConnectionRefused)) }) } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` **System:** - OS: macOS - Architecture: x86_64 - Version 14.1.2 - rustc version: rustc 1.74.0 (79e9716c9 2023-11-13) **Version:** Crate: resolver Version: 0.24.0 **Additional context** Detailed TRACE log: [TRACE.log](https://github.com/hickory-dns/hickory-dns/files/13622991/TRACE.log) Error doesn't exist if we are using `dns-over-native-tls`. Ref: shadowsocks/shadowsocks-rust#1378

kerem closed this issue

2026-03-16 00:45:28 +03:00

kerem commented

2026-03-16 00:45:34 +03:00

Author

Owner

@slatian commented on GitHub (Dec 10, 2023):

For me the same happens with all TLS backends on Linux on 0.24.0. Trust 0.23 works just fine.

@slatian commented on GitHub (Dec 10, 2023): For me the same happens with all TLS backends on Linux on 0.24.0. Trust 0.23 works just fine.

kerem commented

2026-03-16 00:45:39 +03:00

Author

Owner

@cpu commented on GitHub (Dec 10, 2023):

I believe you're hitting the problem described in https://github.com/hickory-dns/hickory-dns/issues/2066:

Try adding the webpki-roots feature to your hickory-resolver dependency features:

[dependencies]
hickory-resolver = { version = "0.24", features = [
    "dns-over-tls",
    "dns-over-rustls",
    "webpki-roots"
] }

@cpu commented on GitHub (Dec 10, 2023): I believe you're hitting the problem described in https://github.com/hickory-dns/hickory-dns/issues/2066: Try adding the `webpki-roots` feature to your `hickory-resolver` dependency features: ``` [dependencies] hickory-resolver = { version = "0.24", features = [ "dns-over-tls", "dns-over-rustls", "webpki-roots" ] } ```

kerem commented

2026-03-16 00:45:44 +03:00

Author

Owner

@slatian commented on GitHub (Dec 10, 2023):

That fixed it for me, thank you!

Enabling native-certs works too.

I guess webpki-roots brings its own certificate store while native-certs is using whatever the system offers as a certificate store (also being a sysadmin I prefer this one).

Was one of these features enabled by default in 0.23?

@slatian commented on GitHub (Dec 10, 2023): That fixed it for me, thank you! Enabling `native-certs` works too. I guess `webpki-roots` brings its own certificate store while `native-certs` is using whatever the system offers as a certificate store (also being a sysadmin I prefer this one). Was one of these features enabled by default in 0.23?

kerem commented

2026-03-16 00:45:49 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 11, 2023):

Yes, this had been a default, but it made it complex if folks want to choose to use one or the other. I think the discussion in the other issue talks a bit about a better path forward.

@bluejekyll commented on GitHub (Dec 11, 2023): Yes, this had been a default, but it made it complex if folks want to choose to use one or the other. I think the discussion in the other issue talks a bit about a better path forward.

kerem referenced this issue

2026-03-16 02:24:39 +03:00

[PR #894] [MERGED] deny all audit warnings #1771