Add support for resolving wildcard subdomains *.localhost

[yonran]

This would solve...

In popular browsers, subdomains of localhost (e.g. http://myserver.localhost) all resolve to loopback [::1, 127.0.0.1]. This is also also specified in the fetch spec.

• Chrome: 2015-03 http://crrev.com/322452 (linked from comment)
• Firefox: 2020-01 https://bugzilla.mozilla.org/show_bug.cgi?id=1220810
• WebKit: not implemented yet https://bugs.webkit.org/show_bug.cgi?id=160504

References:

• https://fetch.spec.whatwg.org/#resolve-an-origin: “If origin’s host’s public suffix is "localhost" or "localhost.", then return « ::1, 127.0.0.1 ».”
• https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 (2013): “ The domain "localhost." and any names falling within ".localhost." are special”… “Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries”

The implementation should look like...

Extract the public suffix, compare it to localhost and localhost. before calling dns.lookup.

I have also considered...

Additional context

This could also be a workaround for a bug resolving non-wildcard localhost itself #1602, since glibc getaddrinfo mistakenly filters out the localhost loopback ipv6 address when you pass in the ADDRCONFIG flag (https://sourceware.org/bugzilla/show_bug.cgi?id=14969).

[metcoder95]

cc: @tsctx @KhafraDev

[mcollina]

This can easily be added as interceptor.

Personally, I think this is better implemented in Node.js itself given the linked RFC.

[KhafraDev]

I think there is something to be fixed in fetch as well, since we skip over https://fetch.spec.whatwg.org/#resolve-an-origin and https://fetch.spec.whatwg.org/#concept-connection-obtain

[FelixVaughan]

Took a stab at the first part of this, suggestions and feedback welcome