Proposal for --upstream flag

[stephen304]

This issue is a proposal for a new flag which would control the behavior of hnsd for queries that were not resolvable by handshake.

The current behavior of hnsd is to attempt to resolve a domain using handshake, and then use a recursive resolver as a fallback to handle ICANN domains.

Motivations:

• The recursive resolver fails if local DNS traffic (all outbound udp port 53) is redirected to a specific DNS server. This could be the case on public wifi.
• The user may want to use a specific DNS server for ICANN domains
• The network may not have internet access (using handshake in an intranet or off-grid setting) and may need to configure a local upstream DNS for local queries

Alternate solutions:

• Can this forward legacy TLD requests to a particular DNS server? #46 suggests using unbound config, which unfortunately seems to take ultimate precedence and redirect everything. Using that method would require maintaining a list of TLDs
• The behavior of the unbound config could be changed to only apply to queries destined for ICANN, at the cost of any current use case that relies on the unbound config

Proposal:
Adding an --upstream flag to change the destination of queries that failed to be resolved by handshake.

• --upstream recursive the current would be default
• --upstream x.x.x.x would use the specified DNS server instead of the built in recursive resolver
• --upstream 2001::0 should accept ipv6 as well

This would avoid interfering with any existing unbound config use case and also not require maintaining a dump of ICANN TLDs while making it easier to handle different network environments.

[pinheadmz]

I started working on an implementation of this, but ran into a snag: specifically what I can do is accept an --upstream option and if set, the root nameserver will return a REFUSED error if a name does not exist in HNS. The problem then is how to instruct the recursive resolver to handle that. hnsd uses unbound as the built-in recursive resolver and we can only configure so much about it.

If the recursive was implemented in raw C here in hnsd, we could add logic to respond to the REFUSED message by forwarding the query to the --upstream server. Unbound does have a ub_ctx_set_fwd() option but then it forwards ALL queries to that server. There are also some fallback options, but they only apply when using a local "auth-zone" which is a hard-coded zone file, and that won't work for us. We configure the unbound recursive with a specific server for a "stub-zone" (which is the "." zone).

So I'm wondering if you have any other ideas about this. I can try a few more things (like adding multiple "stub-zones", which is allowed and I think unbound will try them in order...).

Another thought I had is a bit hacky but we could instantiate a second unbound instance with forwarding set to --upstream and switch to that if the first resolver fails -- seems a bit bulky though...

Also in your issue you mention the possibility of udp:53 being captured or redirected in a hostile WiFi environment (I actually experienced this in a hotel last week and had to use a VPN to get my laptop's HNS resolver to work...). I don't think an --upstream option will help in this case, because the recursive resolver still needs to hit port 53 on nameservers out on the internet to do recursion, handshake or icann or any kind of DNS.

Sorry this issue was on my backlog for so long, I hope you are still interested in Handshake and curious if you have any new thoughts about this particular goal.

[stephen304]

Thanks for your work on this. Does ub_ctx_set_fwd apply only to the recursive part or does it also interfere with the root nameserver? It seems to me that if that could work, it would be ideal (forwarding all non-hns queries to a specific server) unless I'm not understanding fully.

Unfortunately I don't know much about unbound internals so I don't have any additional ideas for implementation.

Edit: Also to respond to your note about LANs with DNS blocked, my personal use case for that is the fact that my LAN is set up to redirect all DNS to my local recursive resolver, which breaks the hnsd recursive resolver. I would solve it by just setting the upstream DNS to my gateway where my local unbound is running.

[pinheadmz]

OK @stephen304 I got a branch for you ;-) #62 I think it still needs work, but it's a good start!

[stephen304]

The forwarding part seems to work as expected - though I'm still unable to resolve hns domains for some reason on either my home network or tethered to my phone. As I noted in the PR, I think it might be a separate bug since I had the same issue before and never figured out what was wrong. I can open a separate issue for that.