dns.lookup('localhost', { all: true}) returns only ::1 with Node.js v22.12, while v22.11 returned both ::1 and 127.0.0.1

[jasongin]

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.1

And 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

[lpinca]

Bisecting points to ecedcba as the first bad commit.