mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #110] Feature: Resolver, add trust-dns-resolver #353
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#353
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 @bluejekyll on GitHub (Mar 27, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/110
Originally assigned to: @bluejekyll on GitHub.
This would be a full resolver that could be used instead of a system resolver.
@bluejekyll commented on GitHub (May 23, 2017):
see #136
@msehnout commented on GitHub (Jun 1, 2017):
It would be nice to have something like dnssec-trigger that could be used with trust-dns-resolver. I'm using dnssec-trigger for validation on my laptop and it kind of works, but it'd be nice to have project with more welcoming upstream and not written in plain C.
@bluejekyll commented on GitHub (Jun 1, 2017):
What do you use dnssec-trigger for? It looks like it validates DNSSec RRSIGs if I understood the about page. TRust-DNS does already support this. For the resolver it will just be a matter of swapping in the validating when creating a resolver. I'll try and make sure I have examples for this.
@msehnout commented on GitHub (Jun 1, 2017):
dnssec-trigger itself is used just to configure unbound resolver according to my network configuration. It works something like this:
When I connect to a network, NetworkManager has a hook that will send network configuration to dnssec-trigger.
Dnssec-trigger then performs a probing, which means it tries to use DHCP provided resolvers for DNSSec validation.
Then it configures Unbound resolver according to probe results. It should configure unbound in such a way, that internal queries are not sent outside of a corporate network and ideally it should also send reverse queries to the proper resolver.
I hope this explanation is not completely messed up. For more information you can check out this Fedora wiki page:
https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC
@bluejekyll commented on GitHub (Jun 26, 2017):
FYI, I just landed this feature in master. I'll be publishing a crate in the next few days.
For the feature you mentioned above. I'm not sure it's something that I will necessarily work on, but if you want to create an issue for it, we can track it and see if anyone else is interested in that?