Handle ENOENT Windows lookup failures #50
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #49
This can happen when, for example, you query with
{family:6}
on Windows but only IPv4 resolution is available.It's very difficult to pin down all the possible error cases for DNS, but I think this happens because:
uv__getaddrinfo_translate_error
in libuv for Windows falls back touv_translate_sys_error
(here)uv_translate_sys_error
mapsWSANO_DATA
toENOENT
(here)WSANO_DATA
is returned by Windows when the name exists, but not the requested record type. See https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2, which says:This shouldn't ever be returned on Unix OSs, which have their own separate & fixed list of possible errors (here).
There's more discussion and an (unmerged) PR to fix this properly and line up Unix & Windows DNS error handling here: libuv/libuv#2959