Description
Version
v22.12.0
Platform
Windows 11 (Microsoft Windows NT 10.0.26100.0 x64)
Subsystem
dns
What steps will reproduce the bug?
On my Windows 11 system, the localhost hostname resolves to both ::1 and 127.0.0.1, as confirmed by PowerShell Resolve-DnsName:
PS> Resolve-DnsName localhost
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
localhost AAAA 1200 Question ::1
localhost A 1200 Question 127.0.0.1And with Node.js v22.11 (and v20, and v18), both addresses are returned by a DNS lookup, as expected:
PS> node -v
v22.11.0
PS> node -e "require('dns').lookup('localhost', {all: true}, (err, addresses) => console.log(JSON.stringify(addresses, null, ' ')))"
[
{
"address": "::1",
"family": 6
},
{
"address": "127.0.0.1",
"family": 4
}
]However with Node.js v22.12, only ::1 is returned:
PS> node -v
v22.12.0
PS> node -e "require('dns').lookup('localhost', {all: true}, (err, addresses) => console.log(JSON.stringify(addresses, null, ' ')))"
[
{
"address": "::1",
"family": 6
}
]How often does it reproduce? Is there a required condition?
It repros consistently on Windows.
I do not see the same problem on Linux: after editing /etc/hosts to include dual mappings for localhost, I do see both addresses returned from the Node.js DNS lookup, and it is consistent between Node.js v22.11 and v22.12.
What is the expected behavior? Why is that the expected behavior?
I found this bug because we have some Node.js test code that needs to connect to a port on localhost without knowing whether the local server is listening on the IPv4 or IPv6 localhost. It actually uses net.createConection({..., autoSelectFamily: true }), but the problem seems to be with the DNS resolution before the "happy eyeballs" algorithm gets a chance to auto-select an address family. Because only ::1 is tried, the connection fails if the local server was actually listening on IPv4.
What do you see instead?
Error: connect ECONNREFUSED ::1:51793
...when the server was actually listening on 127.0.0.1:51793
Additional information
No response