hsd icon indicating copy to clipboard operation
hsd copied to clipboard

Fix ipv6 support for DNS servers

Open pinheadmz opened this issue 2 years ago • 3 comments

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

pinheadmz avatar Mar 03 '22 18:03 pinheadmz

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.

pinheadmz avatar Aug 16 '22 13:08 pinheadmz

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.

rithvikvibhu avatar Aug 16 '22 16:08 rithvikvibhu

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

pinheadmz avatar Aug 17 '22 21:08 pinheadmz