hsd
hsd copied to clipboard
Fix ipv6 support for DNS servers
Requires https://github.com/chjj/bns/pull/33
Inspired by https://github.com/handshake-org/hsd/pull/685 I went looking for other problems with 127.0.0.1
and tried configuring hsd's DNS servers to listen on ipv6 addresses ::1
. There were several problems with this that need to be addressed in both bns (see above PR) as well as hsd.
The misbehavior can be observed on master branch:
- start hsd with
hsd --rs-host=::1
- try to
dig @::1 ...
Other combinations will also break such as hsd --ns-host=::1
and then dig @127.0.0.1 ...
because the recursive resolver (unbound
) thinks ipv6 is false and will just return SERVFAIL
even though the root name server is happily listening on ::1
REVIEWERS: be sure to rm -rf node_modules && npm i
because this PR pulls in the bns PR
Turns out our initial approach to IPv6 stuff was a little off and required a follow-up: https://github.com/handshake-org/hsd/pull/723
see also https://github.com/handshake-org/hsd/issues/722 and related issues from there.
I'd like @nodech input on this PR and the change to bns before we merge.
I think this PR only enables IPv6, not use it by default when available.
Saw the reverted localhost change, this shouldn't be a breaking change since it still defaults to IPv4 127.0.0.1.
Ok I looked through this all again, here's my current understanding:
First of all - the ipv6 setting for unbound (do-ip6: yes
) means two things:
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#term-do-ip6-yes-or-no
It both listens to ::1
but also uses AAAA
records to query nameservers on ipv6. This means the original plan here of allowing the rs to listen on ::1
even if the user doesn't have actual ipv6 access doesn't make sense.
Next, bns: the default inet6
option is determined by the operating system telling nodejs that it has PUBLIC ipv6 addresses. This certainly garuntees ipv6 access but could also be very false-negative. The bns PR I opened will tell us if we have ANY ipv6 interfaces but since that includes ::1
it could be a false positive (sure we have ::1
but that doesn't mean we can actually use ipv6)
so solution-wise: there is this test in bns which checks for ipv6 access in really the only possible way: try it. But I think relying on a hard-coded external IP address, even a icann dns root server, is sorta problematic.
In discussions, Nodar suggested that we trust the user. Meaning, if the user sets --rs-host
to an ipv6 address, then we just switch inet6: true
and hope they know what they are doing. So to accomplish that, I think THIS hsd PR would stay as-is (remove the hard coded inet6: false
) and then the bns PR will have to change. Over there, we'll keep the "pass inet6 option to unbound" but then instead of Use less-restrictive method to determine default IPv6 status, maybe we trust the user's host
option