OPNSense package

[stephen304]

It would be great if you guys could package hsd for opnsense, which would make it super easy to add handshake resolving support to unbound network-wide.

[pinheadmz]

Interesting idea - can you provide any more details? Are you a maintainer/contributor to opnsense or know someone? Anyone can join or telegram group: https://t.me/hns_tech or IRC #handshake and we can discuss further. We desperately need more contributors to the Handshake project -- not sure how long it will be before someone has spare cycles for this integration.

[stephen304]

I'm unfortunately not involved with opnsense packaging, but I'm also involved with a mesh networking project that is interested in running handshake resolution on each mesh node so that users of the mesh don't have to rely on access to the clearnet. I realize now that it may make more sense for this issue to be on the hnsd repo, since that would be more suited to embedded devices.

The one caveat I can see is that it's unclear how handshake can integrate into an existing unbound config - the readme in this repo hints at being able to supplement a running unbound daemon with handshake capabilities, but so far I have only been able to get hsd and hnsd to act as a non-forwarding standalone resolver, which isn't as helpful since I need unbound to only redirect handshake domains to hsd/hnsd and still recursively resolve regular domains.

Beyond that, it should be pretty straightforward for anyone familiar with packaging. I know someone who may have time for an openwrt package, but I was hoping on testing such a setup locally with my opnsense router before adding it to our mesh node builds. I'm just wary of installing stuff outside of the opnsense package manager since I think the appliance-os nature of opnsense may blow away any added stuff when updating.

[pinheadmz]

hsd and hnsd both implement two resolvers: an authoritative nameserver over the HNS root zone, and a recursive resolver. The recursive resolver always tries to resolve against the HNS root zone first. If the TLD in the query is not present in the HNS root zone, the recursive resolver starts over using the ICANN root zone. In this sense, the HNS resolvers "fall back" to the ICANN root. Until there is a collision between the two namespaces, this means that users can install HNS resolvers and go about all their normal DNS without interruption (and even perhaps an additional boost in privacy since they are no longer using 1.1.1.1 or whatever). These users can also of course begin to resolve HNS names.

hsd and hnsd both use the unbound recursive resolver, so they are designed to be drop-in replacements for whatever recursive resolver a system is currently using. There are issues to iron out, etc but it's supposed to work this way.

I understand if an application wants to do this process in reverse ie. check ICANN root first and then try HNS root if that fails, and this is easy to configure. In addition, the HNS resolvers can be used just for their authoritative root zone name servers and integrate that way into any existing DNS resolver as a plugin.

[stephen304]

Gotcha, in that case it sounds like the appropriate solution for a router is to replace unbound with hnsd, since it sounds like you are saying that hsd can't be implemented in a way where lan devices can resolve both icann root and handshake. Do you have a resource on how to configure the reverse order for hnsd? I don't see any mention of that feature in the hnsd repo. I would also want the ability to specify upstream dns since our mesh nodes may need to prefer other alternate roots in the future (such as opennic).

Also, I realize I misspoke - the openwrt base I'm working with is using dnsmasq for dns, but I think if I can configure hnsd as above with the reverse order and a custom upstream dns server, then I can just direct it to pass all dns to hnsd.

[pinheadmz]

DNS forwarding is possible by configuring unbound (see handshake-org/hnsd#46) but I haven't experimented with this myself. And to be clear, both hsd and hnsd WILL resolve all ICANN-rooted domains, but ONLY if the TLD is not found in the HNS root. I have been using HNS resolvers all year without any disruption in my internet connection or name resolution, plus I get the added benefit of HNS domains.

There is currently no way to configure the priority of the resolvers root zones, it's hard coded in hnsd here and in hsd here

also, both hsd and hnsd run authoritative name servers over the HNS root that are accessible on separate ports, so you can bypass the built in recursive resolvers altogether without any special configuration.

[stephen304]

Thanks that's very useful - I didn't notice that config parameter before. The problem I'm having now is that it seems I can't resolve hns domains. The forwarding seems to work fine which I've set with this unbound config:

forward-zone:
        name: "."
        forward-addr: 192.168.1.1

sudo hnsd -p 4 -r 127.0.0.1:53 -u /etc/unbound/unbound.conf

Maybe I just need examples of hns domains with A records - I tried dig A @127.0.0.1 handshake. and dig A @127.0.0.1 sci-hub.hns, but digging either of those with nextdns and handshake enabled on nexdns doesn't seem to work either so idk what's wrong.

Authoritative mode might come in handy if I set up unbound / dnsmasq to retry failed lookups with hnsd. I'll look at that at a later date.

[pinheadmz]

What resolver is running at 192.168.1.1 in your example? It's going to get ALL DNS requests right? Because "." is interpreted as the ICANN root zone, so if that is a legacy resolver, it won't be able to resolve HNS names.

You might find this suggestion uesful in the other thread: handshake-org/hnsd#46 (comment)

I'm not sure a better way to deal with this yet.

[stephen304]

@pinheadmz I thought that hnsd was supposed to try hns domains before using legacy dns? 192.168.1.1 is indeed a legacy resolver, but I am trying to use the behavior you mentioned earlier to my advantage: both hsd and hnsd WILL resolve all ICANN-rooted domains, but ONLY if the TLD is not found in the HNS root

Does that not hold true when using forward-addr? I even tried adding forward-first: no but that seems to not help. This seems like it would be a bug in hnsd if the resolve order doesn't respect forward-addr

[pinheadmz]

hm I havent played with the forwarding myself but it sounds like its forwarding "." before doing anything (including checking HNS root zone) right?

[stephen304]

Yep that seems to be the case. That bash script is clever for a workaround but for packaging purposes I'm hoping to find a config that uses hsd/hnsd's knowledge of which domains belong to hns.

I'm really unsure if this is working properly in the first place - simply running sudo hnsd -p 4 -r 127.0.0.1:53 I can't seem to resolve any hns domains and no records seem to come back. Using sudo hsd --ns-port 53 I am able to at least get ns records:

dig A welcome.nb 

; <<>> DiG 9.16.10 <<>> A welcome.nb
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37465
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;welcome.nb.			IN	A

;; AUTHORITY SECTION:
nb.			21600	IN	NS	ns1.nb.

;; ADDITIONAL SECTION:
ns1.nb.			21600	IN	A	44.231.6.183

;; SIG0 PSEUDOSECTION:
.			0	ANY	SIG	0 253 0 0 20210120011613 20210119131613 60235 . 2DzIk4ZdEB41VT3pXU88TF7SnlTb7Tqpq1KHb2HxSHA629FrREG0N3ax kO3GI0+EniK3Js3DUs3+VDWdkP9VAw==

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 19 14:16:13 EST 2021
;; MSG SIZE  rcvd: 167

But I can't browse to welcome.nb, sci-hub.hns, handshake., etc. I just realized that I can load welcome.nb through welcome.nb.hns.to, so I think something must be wrong with my setup.

[pinheadmz]

Hm, I just ran hnsd with default parameters, waited for it to sync to height 51331 (current chain tip) and got the recursive to work. Are you getting nothing back from the recursive resolver? Some users have had issues with the hnsd recursive being unable to make requests to its own authoritative resolver (port 5350 and 5349 respectively by default) because they are also running some other DNS software on their machine like adguard.

Meanwhile - what are you trying to do with the forwarding? (sorry). By default hnsd and hsd will resolve ICANN and HNS names, with HNS being the priority. Are you trying to set it up so that ICANN is the priority? Or configure so that the HNS root isn't even checked unless you're sure an HNS name is being requested?

$ dig @127.0.0.1 -p 5350 welcome.nb

; <<>> DiG 9.16.10 <<>> @127.0.0.1 -p 5350 welcome.nb
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2636
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;welcome.nb.                    IN      A

;; ANSWER SECTION:
welcome.nb.             3600    IN      A       134.122.24.75

;; Query time: 854 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1)
;; WHEN: Wed Jan 20 10:02:05 EST 2021
;; MSG SIZE  rcvd: 55

[stephen304]

Oddly enough, running hnsd bare still doesn't seem to work for me:

chain (51346): adding block: 000000000000000389bc741edc9a5a6384cfd34e450a3f33040c090fbc6a14ee
chain (51347):   added to main chain
chain (51347):   new height: 51347

dig @127.0.0.1 -p 5350 welcome.nb

; <<>> DiG 9.16.10 <<>> @127.0.0.1 -p 5350 welcome.nb
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13815
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;welcome.nb.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1)
;; WHEN: Wed Jan 20 13:02:50 EST 2021
;; MSG SIZE  rcvd: 39

The use case I am trying to solve is if an end user would like to use a custom DNS server for various reasons - it could be the DNS filtering features of various public DNS servers, or a non-icann root such as opennic, or maybe they want to (we would configure it for them) use the DNS provided by their gateway VPN to avoid DNS leaks. Our mesh nodes could also lack clearnet access, so the icann resolver would fail if gatewaying out of the mesh isn't configured. Crucially, we want to retain the flexibility to use in-mesh DNS if necessary (via 200::/7 ipv6 mesh addresses). I plan on adding hnsd to openwrt builds that end users will be using, and I don't want to explain to laypeople why they have to choose between being able to visit handshake websites and using a custom DNS server. Most people expect to be able to go to their router settings and paste an IP address to use, and that's essentially how the current DNS settings work.

Being able to re-order the priority would be a nice to have, but the crux of the situation is that we want to be able to use a custom upstream server for various reasons - traditional DNS may not be accessible or the user may want a specific DNS server for particular features, and it feels pretty dirty to do a hack like that bash script in something an end user will be using (especially since it requires clearnet access to get the list of TLDs).

Edit: I also tried building the latest master branch of hnsd and still got the same result. Is it normal to get a bunch of "unknown command: 6"?

[pinheadmz]

"unknown command: 6"

Don't worry about this - hnsd only recognizes a few of the p2p protocol messages used by hsd. I think 6 is INV which is irrelevant to hnsd and the calling peer won't care if there's no response. That's a loose end though and a FAQ so we should do something about it.

[pinheadmz]

Anyway your use case of "only query HNS when we know it's an HNS name" has come up in other contexts as well. For a different project we're discussing using a bloom filter or some other sort of compact list to determine is a TLS is in the HNS root zone or not. Another option is to add this kind of feature to hsd (the full node) and perhaps enable a "root zone dump" file to be committed in the block headers so the entire zone file can be delivered regularly and trusted by light clients.

[stephen304]

@pinheadmz The order of query is actually pretty minor to me, the real gamebreaker for me is the fact that the upstream forward zone gets all HNS queries too. I figured out that my issue is caused by all DNS on my network being redirected, which could easily be the case for one of our mesh devices as well (for example if it was connected to the internet through a public hotspot that redirects all DNS to a custom server in order to display a captive portal).

It seems to me that the ideal solution would be to change the behavior of hnsd to only forward queries to the unbound config defined forward-zone if a handshake lookup fails, similar to how currently, hnsd will only use the ICANN recursive resolver for traditional TLDs if the handshake lookup failed, or by adding a separate option to switch recursive resolve mode to forward mode, which might be preferable if you want to preserve any use cases involving the unbound config options.

For example, an --upstream flag that defaults to recursive but allows you to set it to an IP to use as an upstream server, without changing the current behavior that when a query cannot be resolved by HNS, it goes to upstream.

This imo would make it easier to setup handshake network-wide and not require handling or updating root dumps.

[pinheadmz]

It seems to me that the ideal solution would be to change the behavior of hnsd to only forward queries to the unbound config defined forward-zone if a handshake lookup fails, similar to how currently, hnsd will only use the ICANN recursive resolver for traditional TLDs if the handshake lookup failed, or by adding a separate option to switch recursive resolve mode to forward mode, which might be preferable if you want to preserve any use cases involving the unbound config options.

For example, an --upstream flag that defaults to recursive but allows you to set it to an IP to use as an upstream server, without changing the current behavior that when a query cannot be resolved by HNS, it goes to upstream.

Ok great --- could you open a specific issue for this? Sounds good as a solution

[stephen304]

Sure, I'll open one on the hnsd repo. Also this issue could be closed since I really intended to open this on hnsd.

[pinheadmz]

Thanks @stephen304 ! Continuing discussion on handshake-org/hnsd#53