Allow configurable --upstream recursive resolver for non-HNS queries #62
Conversation
|
This looks good, and I'm able to successfully forward standard dns to my router with
hnsd output: Edit: This may be unrelated to this patch, and I think this is the same problem from before that I never figured out. I can reproduce it on home internet as well as mobile tethering (though the output looks different) so maybe I should open a separate issue for this. |
|
I was able to resolve For example, the HNS name HNS names that resolve directly without delegating to ICANN are working on this branch though, you can try |
|
Great welcome.nb works when tethered to my phone so on normal networks it works as intended. I think I figured out definitively that my router's port 53 outbound redirect is messing up hnsd, anytime that rule is active on my router, hns resolution seems to be broken. I'll put the details in a new issue since I have it reproducible now. |
|
does your router allow any recursive dns traffic? Because even if the root resolution is done internally, the recursive resolver will still need to make requests to port 53 on all the authoritative nameservers for each zone it needs to query |
|
Ah I didn't realize that, the rule that everyone typically uses for redirecting chromecast to pihole involves redirecting all outbound udp traffic on port 53 to the pihole. Wouldn't this mean that hns resolution itself would not work on a hostile network that tampers with traffic on port 53? Is there any way to make the recursive resolver use the upstream setting for authoritative queries? I'm not sure how that works so maybe that doesn't make sense.
|
Correct, in my hotel last week I experienced this and had to use a VPN to get any kind of local-recursive DNS resolution to work. I still think this is a useful option to add to hnsd since the hard-coded root zone may be out of date. And I think pi-hole should still work in this configuration, but I'm not entirely sure how pihole works. |
|
Yeah definitely useful regardless. I can set my --upstream to my pihole and that works as well, doubleclick.net resolves to 0.0.0.0. The only issue is my catchall rule, which I admit is a bit niche. But on the other hand, handling not having access to recursive resolving abilities, including a case where the clearnet is completely inaccessible, would solve the use case of using hns on an isolated intranet or mesh network where clearnet access isn't available at all, I think I mentioned before we have mesh nodes that may have spotty clearnet access, but could potentially connect to other hns peers who do have clearnet access over the mesh. So being able to resolve hns domains when only the hns network is accessible would be a nice to have. Regardless, this is a good step towards enabling hnsd on a wider variety of configurations. |
|
So, unfortunately I think I need cut bait on this one for now and come back to it later, it may require a much bigger refactor or actually patching up libunbound to bend to our will. Here's what I learned:
request: request: request: So, in 535a2bf I tried moving the fallback resolver to root server in place of the hard-coded ICANN lookup, but this didn't really work either. It might, but it's going to need a lot more hacky code, because what we want to do is convert an authoritative request into a recursive request, and the data types are all different (hns resource serialization vs unbound result struct). The ideal fix for this is a wild configuration for the unbound recursive resolver itself that says "if the stubbed root zone returns NXDOMAIN, give up and forward an entirely new request to this upstream recursive..." |
|
Gotcha, thanks for your work so far on this! |
Closes #53
This PR allows the user to pass the address of an "upstream" recursive resolver to hnsd, which is used when a query fails to resolve from HNS root zone instead of the typical built-in "ICANN fallback" implemented in the root nameserver itself.
Example usages:
hnsd --upstream 1.1.1.1hnsd -t 10.0.1.200:5350The main changes to hnsd when
--upstreamis passed in:When the root nameserver (
ns) gets a proof of nonexistence from the HNS network, instead of looking up the name in the hard-coded ICANN root zone file and resolving there, thensreturns an error:REFUSEDOn launch, the recursive resolver (
rs) normally spawns an unbound context and configures thensserver as a stub server for the"."zone. This still happens - but IN ADDITION, a second unbound context is spawned (calledfallback) configured withub_ctx_set_fwd()meaning ALL queries are forwarded to an upstream recursive resolver.All responses from the primary
rsunbound instance are inspected after they are resolved. If the response from unbound isSERVFAIL, the request is passed to thefallbackinstance of unbound.Observe in the logs: (using
hnsd -t 1.1.1.1)Disclaimer
I think this PR is a bit smelly. Creating an entire second recursive resolver seems like a bit much, but I couldn't think of any other way to do this, because unbound requires all this configuration up front before opening (like setting a stub zone). So with unbound, either all requests get forwarded, or all requests get sent to the specified root zone server. I may try to experiment with other approaches using the same unbound instance but the configuration options are limiting.
It also means there is a second unbound worker and worker thread. This made closing the program cleanly tricky because of funny async stuff in the original design which never intended for there to be more than one unbound thread.
Finally, the "trick" isn't perfect either. I'm using the
REFUSEDerror message from rootnsto unbound to trigger the fallback resolution, but by the time unbound returns the response, its been glossed over with a simpleSERVFAIL. This could mean that ANY error fromnsbeing interpreted asSERVFAILby unbound will lead to the fallback resolution. This can probably be switched toNXDOMAINsince the rootnsisn't checking the ICANN zone at all in this mode.