mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 11:15:54 +03:00
[GH-ISSUE #55] [Server] Add Forwarding Zone support #37
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#37
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 @rbmj on GitHub (Oct 25, 2016).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/55
I'm fairly new to rust, so with the understanding that I could be completely wrong about all of this...
It appears that there isn't any support for forwarding zones. Though a zone file can be declared as a forwarding zone, there isn't actually any support for this behavior in the code - it appears to treat all zones the same for lookup purposes.
It appears like
Authority::lookup()andCatalog::find_auth_recurse()would be the primary areas that would need to be modified, along with the requisite configuration changes.I'm interested in contributing code, and would be willing to try and implement this if I'm not mistaken.
Thanks!
@rbmj commented on GitHub (Oct 25, 2016):
As an aside: I assume this is a configuration issue on my end, but I get "Address already in use" panics if I don't comment out the IPv6 listeners in
named.rs@bluejekyll commented on GitHub (Oct 25, 2016):
Thanks for the comments! Yes, you are correct that zone forwarding is currently not supported.
I should make a note of that in the configs/docs if it's not clear right now. Currently there is only support for the Server to act as an Authority. I don't think this would be hard to add, I haven't done it yet, because I think there is a bigger story around a full caching Resolver there, that should be spec'ed out. What I've been thinking of for Resolvers/Forwarders is to implement a general purpose caching layer, which would use the Client for all resolution. One of the reasons I haven't worked on a Resolver yet, is that I think there are a lot of nitty-gritty details in the RFCs to get resolution correct.
As to the question of where to add this, I think it would be a separate Catalog, that if the main Authority catalog does not contain the zone, then the Forwarding catalog would be used to perform a lookup and cache the result. It's not a small amount of work by any means ;) But if you want to take a crack at it, that would be awesome.
As to the IPv6 conflict, are you listening on both IPv4 and IPv6? There could definitely be a bug there, I think most of the integration tests are testing them in isolation right now. Also what OS are you on? And mind opening a separate bug for that?
@rbmj commented on GitHub (Oct 25, 2016):
I'll open an issue.
From the design perspective, it would seem to me that the simplest way would be to keep it at a zone based level - you can specify that a zone is a master zone, or a forwarding zone. Then, you could have zone be a trait and have authority and forwarder implement that zone trait. I come from a C++ background, so I have a tendency to want to force polymorphism on everything, but this seems like the simplest way (from my perspective) without having to make major structural changes to the code. Caching could be added on later as another implementation of the zone trait - which would just perform a lookup on a
Box<Zone>and cache the result.@bluejekyll commented on GitHub (Oct 25, 2016):
A Zone trait, which is basically the current Authority, would be nice. Are you thinking of the forwarding zone as acting as just a pass through? Meaning it wouldn't actually store any records? I was assuming a Forwarding zone would definitely want to cache results from the master, but I guess it doesn't have to in it's most basic form.
An FYI: I'm currently finishing up work on the futures-rs based client. I have one last addition/change to make there to resolve an issue, and then that will land. After that I'm planning on going back and reworking the Server around futures-rs as well. It shouldn't change a ton of anything being done in this area, but it will be nice because it will allow a forwarding Zone the ability to share a sync io event loop between the client and server, which isn't possible right now.
@rbmj commented on GitHub (Oct 25, 2016):
It was more to separate things out - easier (IMO) to just worry about caching and allow DNS lookup to happen by magic in one struct, and then only do DNS lookup in another without worrying about caching. To me, it simplifies design enough to be worth an extra pointer indirection, but it's personal preference. It also seems like it would be easier to test/prototype.
@bluejekyll commented on GitHub (Oct 25, 2016):
Sounds great :)
@bluejekyll commented on GitHub (Mar 27, 2017):
Depends on #110
@bluejekyll commented on GitHub (Jun 30, 2017):
With the Resolver done, some thought can be done on potentially integrating it into the Server, though it might be too high level an interface. It might be nice to use the internals of the Resolver like NameServerPool directly so that RecordSets are directly accessible.