search

nodejs / node

Node.js JavaScript runtime ✨🐢🚀✨
https://nodejs.org
Other
106.66k stars 29.09k forks source link

node localhost resolves to 127.0.0.1 instead of ::1 on IPv6-only network #33816

Open kapouer opened 4 years ago

kapouer commented 4 years ago

In a IPv6 only setup that can be reproduced with:

unshare -n
ip li set lo up
ip li add dummy0 type dummy
ip li set dummy0 up

and making sure /etc/hosts has that line

::1     localhost ip6-localhost ip6-loopback

many tests fail E.g. parallel/test-http-localaddress throws Error: bind EINVAL 127.0.0.2.

There is similar problem in Perl, in particular see this message: https://bugs.debian.org/962318#12

mscdex commented 4 years ago

Are you passing dns.ADDRCONFIG to dns.lookup()?

kapouer commented 4 years ago

was not me

bnoordhuis commented 4 years ago

While I can confirm the issue w.r.t. to the test suite, I don't think it's something we need or want to fix. The test suite assumes the availability of IPv4 and that seems fine to me.

kapouer commented 4 years ago

I understand about the test suite being written to be run in an env with IPv4 all right. However i'm not sure that this issue won't show up in various other osx/linux environments ? Reading the perl bug report (link above), it seems assuming using ADDRCONFIG for loopback addresses poses some kind of bug.

bnoordhuis commented 4 years ago

Fair enough. I've removed the test label.

glibc and musl do AI_ADDRCONFIG detection differently:

  1. glibc: when there is any non-loopback ipv4 or ipv6 interface
  2. musl: when there is a 127.0.0.1 or ::1 interface (ref)

That difference in approach makes it complicated to fix on node's end. https://github.com/libuv/libuv/issues/2225 is also relevant.

Node's habit of defaulting hints to AI_ADDRCONFIG papers over some of the differences. I worry that removing it will end up breaking more than it fixes. For sure it broke our CI last time we tried it.