mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 11:15:54 +03:00
[GH-ISSUE #989] Resolver: cloudflare dns over tls possible future leak warning #585
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#585
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nickbabcock on GitHub (Jan 12, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/989
Description
When resolving multiple addresses through a resolver configured for dns over tls using cloudflare's tls configuration, I'm seeing the following warning:
This seems different than #355, so I opened a new issue.
Reproduce
Happens for both the rustls backend and native-tls
Expected
The ipv4 addresses to be listed for each passed argument
Workaround:
System
Version
@nickbabcock commented on GitHub (Jan 12, 2020):
Updated issue: quad 9 dns over tls works fine. It appears only cloudflare is effected.
@bluejekyll commented on GitHub (Jan 12, 2020):
Is it only the error message you’re seeing? Or are you seeing other poor behavior?
@nickbabcock commented on GitHub (Jan 12, 2020):
No other error messages occurred. No poor behavior (the addresses are resolved correctly).
Under debug mode, quad9_tls looks to print an error:
Here are the raw debug logs
cloudflare_tls debug log
quad9_tls debug log
The only thing that pops up to me is that the cloudflare enques two messages (one to 1.1.1.1, 1.0.0.1) when quad9 does only one (only to ... 9.9.9.9).
When I use a cloudflare_tls config of
I do not see the warning (maybe because it now only sends one message?) 🤔
@bluejekyll commented on GitHub (Jan 12, 2020):
This could definitely be related to #933, I haven’t had a chance to look into that one.
@nickbabcock commented on GitHub (Jan 15, 2020):
Yeah it's a bit related to #933, but I can only reproduce it with dns over tls. I don't see the error with plain dns sent to multiple IPs. (I haven't tried dns over tcp to see if that is the culprit), and if it helps, the warning is not spurious -- it repros every time.
A bit of more info, I was able to get the warning to appear with multiple ips for quad 9
So it seems like the best workaround for those that want to rely on (the experimental) dns over tls, to use a
NameServerConfigGroupwith one ip (ResolverConfig::quad9_tls()or create your own with1.1.1.1)@nickbabcock commented on GitHub (Apr 7, 2020):
Not sure if this is quite fixed, using the latest master branch (
git+https://github.com/bluejekyll/trust-dns#76a3776d8840b4915390f241cda94d1f12b0df73), I still receive the following warning with the reproducible snippet in OPLet me know if I can be of assistance.
@bluejekyll commented on GitHub (Apr 7, 2020):
Thank you for check. I’ll reopen.