Hacker News Reader

Comment by rwmj | Hacker News Reader

Netscape used to start a new thread (or maybe it was a subprocess?) to handle DNS lookups, because the API at the time (gethostbyname) was blocking. It's kind of amazing that we're 30 years on and this is still a problem.

View on HN

getaddrinfo_a is available, but not widely adopted (*BSD and Linux), probably because you can't guarantee it'll be available on every computer/phone/modem. This is only an issue if you're targeting POSIX rather than modern operating systems.

Windows 8 and above also have their own asynchronous DNS API on NON-POSIX land.

>Windows 8 and above also have their own asynchronous DNS API on NON-POSIX land. Interesting. Which API?

GetAddrInfoEx[0] has async support support since Windows 8 - it had the overlapped parameters earlier but didn't support them. I'm guessing that is what GP is referring to.

[0] https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip...

>getaddrinfo_a is available, but not widely adopted (*BSD and Linux), probably because you can't guarantee it'll be available on every computer/phone/modem. This is only an issue if you're targeting POSIX rather than modern operating systems.

To be precise, even on Linux getaddrinfo_a is not guaranteed to be present. It's a glibc extension. musl doesn't have it.

And MUSL's explicit policy of "do not implement essential features, just because the standards are falling behind" is a major reason why many programs choose to never support building against MUSL.

Funny, I see it as them choosing not to add another de-facto 'standard' ala https://xkcd.com/927/ .

If you want DNS resolution to obey user/system preferences then you need to use the system provided API

For sure! The only problem is there should be a non-blocking system-provided API and there isn't.

System provided is maybe a strange word to use here since getaddrinfo is a libc function, not a system call.

POSIX as the system, of course.

the system API is not syscalls but libc. so why does it feel strange?

In this case it isn't in the kernel, but in glibc. Could someone implement an equivalent alternative? Do any language runtimes re-implement DNS resolution?

I think most languages use the OS api by default, but there are plenty of libraries out there that bypass the system resolution.

Go does. And it supports timeouts and cancelation.

The system-provided API for getting DNS user/system preferences on Unix systems is to read /etc/resolv.conf. Every application is free to implement their own lookup from that.

That is absolutely not the API on macOS, which is a certified UNIX.

This isn't even correct on Linux as it won't work if your user has anything other than or in addition to the dns module in their nsswitch.conf. You must use glibc's resolution on Linux for correct behavior. If it's software on your own systems then do what you want but you'll piss off some sysadmins deploying your software if you don't. Even Go farms out to cgo to resolve names if it detects modules it doesn't recognize.

In 1996 it was a subprocess. Linux Threads appeared only later that year.

As long as broken APIs exist, they will be problematic... they really should be deprecated.

Calling a separate (non-cancellable) thread to perform the lookup sounds a like viable solution...

Reply on news.ycombinator.com