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.

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.

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

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.