Node: dns: provide additional info for ENOTFOUND errors

[bnoordhuis]

Refs: #5436 - and plenty of other issues.

That issue attracts comments from befuddled users to this day so I think it highlights a real issue, namely that the ENOTFOUND error code on its own is not very helpful.

History/background/context:

1. It's an artificial error that was introduced for $reasons in Node.js v0.2.0.¹

2. It's been around long enough that simply removing it won't fly.

3. It's returned when getaddrinfo() fails with EAI_NODATA or EAI_NONAME.

4. It nearly always indicates some transient or environmental error condition: out of file descriptors, no network connectivity, upstream DNS server timing out, etc.

It would be nice to provide a better error message, perhaps through an additional status property if necessary for backwards compatibility.

The problem: there might not be sufficient metadata to provide a better message.

For example, glibc returns EAI_NONAME when there is no IPv6 connectivity and the host only has an IPv6 address. There is no way to dinstinguish that particular condition from a real NXDOMAIN error apart from opting out from glibc's default behavior (see https://github.com/libuv/libuv/issues/2225 - probably has wider-ranging consequences.)

¹ For the curious: it maps directly to ARES_ENOTFOUND, the c-ares error code. That's from before Node.js supported getaddrinfo().

[sagitsofan]

I think the best way is to retrieve the error description directly from the V8 engine like made in the this #22995 PR using the uvExceptionWithHostPort function.

[bnoordhuis]

@sagitsofan What exactly do you propose? The core issue is not enough context to construct a good error message.

[techieshark]

It nearly always indicates some transient or environmental error condition: out of file descriptors…

@bnoordhuis thanks for this very helpful context!

Do you have any recommendations for how to determine if the underlying issue is related to a failed IPv6 lookup (as suggested in in comments like this https://github.com/nodejs/node/issues/5436#issuecomment-189474356) vs something like a lack of file descriptors etc?