starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #1412] bad dns_name: 1.1.1.1 #666

New issue

Closed

opened 2026-03-15 23:44:30 +03:00 by kerem · 11 comments

kerem commented

2026-03-15 23:44:30 +03:00

Owner

Originally created by @onoketa on GitHub (Mar 14, 2021).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1412

Describe the bug
bad dns_name: 1.1.1.1 when using 1.1.1.1 as tls_dns_name in ResolverConfig

To Reproduce

let mut resolver = ResolverConfig::new();
				resolver.add_name_server(NameServerConfig {
					//...
					protocol: trust_dns_resolver::config::Protocol::Https,
					tls_dns_name: Some("1.1.1.1".to_string()),
					//...
					//...
				});

Expected behavior
https://1.1.1.1/dns-query is a valid DoH service so it should not be a bad dns name

System:

OS: Arch Linux
Architecture: x86_64
Version 5.10.23
rustc version: 1.48.0

Version:
Crate: resolver
Version: 0.20

Originally created by @onoketa on GitHub (Mar 14, 2021). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1412 **Describe the bug** ```bad dns_name: 1.1.1.1 ``` when using 1.1.1.1 as ```tls_dns_name``` in ```ResolverConfig``` **To Reproduce** ```rust let mut resolver = ResolverConfig::new(); resolver.add_name_server(NameServerConfig { //... protocol: trust_dns_resolver::config::Protocol::Https, tls_dns_name: Some("1.1.1.1".to_string()), //... //... }); ``` **Expected behavior** ```https://1.1.1.1/dns-query``` is a valid DoH service so it should not be a bad dns name **System:** - OS: Arch Linux - Architecture: x86_64 - Version 5.10.23 - rustc version: 1.48.0 **Version:** Crate: resolver Version: 0.20

kerem

2026-03-15 23:44:30 +03:00

closed this issue
added the
enhance

crate:resolver

feature:dns-over-https

feature:dns-over-tls
labels

kerem commented

2026-03-15 23:44:46 +03:00

Author

Owner

@djc commented on GitHub (Mar 14, 2021):

The rustls stack doesn't support connecting to IP addresses over TLS. You can use the domain name or switch to native-tls via the relevant feature flags.

@djc commented on GitHub (Mar 14, 2021): The rustls stack doesn't support connecting to IP addresses over TLS. You can use the domain name or switch to native-tls via the relevant feature flags.

kerem commented

2026-03-15 23:44:52 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 14, 2021):

Additionally, I don't believe that is the correct SNI for Cloudflare, which I'm nearly certain is cloudflare-dns.com. For ease of use you can just use the Cloudflare configs baked in: ResolverConfig::cloudflare_https.

@bluejekyll commented on GitHub (Mar 14, 2021): Additionally, I don't believe that is the correct SNI for Cloudflare, which I'm nearly certain is `cloudflare-dns.com`. For ease of use you can just use the Cloudflare configs baked in: `ResolverConfig::cloudflare_https`.

kerem commented

2026-03-15 23:44:57 +03:00

Author

Owner

@onoketa commented on GitHub (Mar 15, 2021):

Additionally, I don't believe that is the correct SNI for Cloudflare, which I'm nearly certain is cloudflare-dns.com. For ease of use you can just use the Cloudflare configs baked in: ResolverConfig::cloudflare_https.

When you connect with 1.1.1.1 there is no SNI in client hello. In China, connecting to 1.1.1.1 with SNI 'cloudflare-dns.com' is blocked by the Great Firewall. It will be helpful if connecting without SNI is supported in trust-dns's DNS over HTTPS resolver.

@onoketa commented on GitHub (Mar 15, 2021): > Additionally, I don't believe that is the correct SNI for Cloudflare, which I'm nearly certain is `cloudflare-dns.com`. For ease of use you can just use the Cloudflare configs baked in: `ResolverConfig::cloudflare_https`. When you connect with 1.1.1.1 there is no SNI in client hello. In China, connecting to 1.1.1.1 with SNI 'cloudflare-dns.com' is blocked by the Great Firewall. It will be helpful if connecting without SNI is supported in trust-dns's DNS over HTTPS resolver.

kerem commented

2026-03-15 23:45:02 +03:00

Author

Owner

@djc commented on GitHub (Mar 15, 2021):

As I mentioned, I think this would work with the openssl or native-tls support already available in the resolver crate. You just have to configure it using the crate's Cargo features.

@djc commented on GitHub (Mar 15, 2021): As I mentioned, I think this would work with the openssl or native-tls support already available in the resolver crate. You just have to configure it using the crate's Cargo features.

kerem commented

2026-03-15 23:45:07 +03:00

Author

Owner

@onoketa commented on GitHub (Mar 15, 2021):

As I mentioned, I think this would work with the openssl or native-tls support already available in the resolver crate. You just have to configure it using the crate's Cargo features.

DNS over HTTPS resolver has only rustls support.

@onoketa commented on GitHub (Mar 15, 2021): > As I mentioned, I think this would work with the openssl or native-tls support already available in the resolver crate. You just have to configure it using the crate's Cargo features. DNS over HTTPS resolver has only rustls support.

kerem commented

2026-03-15 23:45:12 +03:00

Author

Owner

@djc commented on GitHub (Mar 15, 2021):

Ah, sorry, I missed that. Maybe we could have an tls_enable_sni option for NameServerConfig (conditional on rustls features) to the https::HttpsClientStreamBuilder (and probably also the dns_over_rustls stream builder) which can propagate the flag into the rustls ClientConfig. @bluejekyll what do you think?

@djc commented on GitHub (Mar 15, 2021): Ah, sorry, I missed that. Maybe we could have an `tls_enable_sni` option for `NameServerConfig` (conditional on `rustls` features) to the `https::HttpsClientStreamBuilder` (and probably also the `dns_over_rustls` stream builder) which can propagate the flag into the rustls `ClientConfig`. @bluejekyll what do you think?

kerem commented

2026-03-15 23:45:17 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 15, 2021):

I think that sounds fine. We could always add OpenSSL/NativeTLS support, though I've been thinking of dropping OpenSSL and leaning more on Rustls/ring in the long run, I just never got around to it myself.

I'm forgetting about SNI right now in terms of security in TLS. Does SNI add any security to the protocol, or is it purely for server-side multi-homing?

@bluejekyll commented on GitHub (Mar 15, 2021): I think that sounds fine. We could always add OpenSSL/NativeTLS support, though I've been thinking of dropping OpenSSL and leaning more on Rustls/ring in the long run, I just never got around to it myself. I'm forgetting about SNI right now in terms of security in TLS. Does SNI add any security to the protocol, or is it purely for server-side multi-homing?

kerem commented

2026-03-15 23:45:22 +03:00

Author

Owner

@djc commented on GitHub (Mar 15, 2021):

I don't think SNI is important for security.

@djc commented on GitHub (Mar 15, 2021): I don't think SNI is important for security.

kerem commented

2026-03-15 23:45:27 +03:00

Author

Owner

@trinity-1686a commented on GitHub (Apr 19, 2021):

Does SNI add any security to the protocol

Some would argue that SNI decrease security as it leaks information on the service being reached, creating the need for something like Encrypted SNI.

@trinity-1686a commented on GitHub (Apr 19, 2021): > Does SNI add any security to the protocol Some would argue that SNI decrease security as it leaks information on the service being reached, creating the need for something like [Encrypted SNI](https://tools.ietf.org/html/draft-ietf-tls-esni-10).

kerem commented

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

Author

Owner

@djc commented on GitHub (Nov 1, 2022):

Yes, it looks like DNS over HTTPS is currently only supported with rustls. If you want, consider submitting a PR to add a dns-over-https-native-tls feature (which probably wouldn't be very hard, mostly just a bunch of copy and pasting from the dns-over-https-rustls code -- though of course we'd prefer to abstract over the difference instead of outright copying where possible).

(As a rustls co-maintainer, rustls is likely to have support for IP address in certificates by the end of January.)

@djc commented on GitHub (Nov 1, 2022): Yes, it looks like DNS over HTTPS is currently only supported with rustls. If you want, consider submitting a PR to add a `dns-over-https-native-tls` feature (which probably wouldn't be very hard, mostly just a bunch of copy and pasting from the `dns-over-https-rustls` code -- though of course we'd prefer to abstract over the difference instead of outright copying where possible). (As a rustls co-maintainer, rustls is likely to have support for IP address in certificates by the end of January.)

kerem commented

2026-03-15 23:45:37 +03:00

Author

Owner

@djc commented on GitHub (May 30, 2023):

For people following along here, the trust-dns 0.23.0-alpha.1 release depends on the new rustls release and should support connecting to IP addresses.

@djc commented on GitHub (May 30, 2023): For people following along here, the trust-dns 0.23.0-alpha.1 release depends on the new rustls release and should support connecting to IP addresses.

kerem referenced this issue

2026-03-16 02:14:37 +03:00

[PR #666] [MERGED] localize clippy allowance #1586