[OTish] getaddrinfo(), DNS client library (was: Crash in gethostbyname() on congruent usage)

[Laurent Bercot]

> I don't see how getaddrinfo was "designed to accommodate NSS". It's
> designed to abstract the operation of translating host and service
> names to addresses from the underlying implementation (DNS). This is a
> fairly important abstraction, especially with IPv6 in mind; if you
> application were just sending DNS A requests, it would break when the
> user needs to switch to IPv6. With proper use of getaddrinfo, you
> never even allocate any address-family-specific sockaddr structures
> yourself, and your application works transparently with IPv4, IPv6,
> and any hypothetical future protocols.

 It's not exactly hard to write a function that sends an A query when
the underlying protocol is IPv4 and an AAAA one when the underlying
protocol is IPv6. getaddrinfo() offers that convenience, for sure, but
it's pretty minor when you compare it to its drawbacks. What if I *want*
to explicitly perform an A query, no matter the underlying protocol ?
What if I want an MX query ? getaddrinfo() is barely good enough for
name-to-address translation, but it is not a DNS tool. I consider it a
terrible waste that the libc has to implement the major part of a DNS
client library, only to offer the getaddrinfo() entry point to the user.


> I don't think you can implement a good
> general-purpose asynchronous lookup interface without threads anyway,
> unless you're going to require that the caller have a select/poll
> based event loop and make calls back into the lookup function on each
> event. If you have a design for one, I'd love to see it...

 Not only do I have a design for one, but I also have an implementation,
and I'm using it every day. It's not published yet because it's severely
lacking documentation, but it works flawlessly, it's small, and I find
it much easier to use than the alternatives.
 Synchronous calls are as easy as
 s6dns_resolve_aaaa(&result, name, namelen, options, deadline, &stamp)
There are of course single-threaded and still flexible enough.
("stamp" is an absolute timestamp that should be close enough to the
current time; if the "deadline" time is reached during the call, the
function immediately returns -1 ETIMEDOUT.)
 I am currently in the process of making the whole library IPv6-compatible.
With a bit of luck, everything will be ready and documented in a few months,
and I'll be able to publish it.

 I know you are a huge multithreading advocate. I am a huge multithreading
opponent. ;) So far, the only program I have felt threads were
*necessary* to implement properly was an IRC server, and it was for
optimization purposes - multiprocessing just caused too much
context-switching overhead with unneeded data duplication and copy via
the pipes. But something as easy as a DNS client library can totally be
done with an event loop.


> I agree proxying should be done by an external DNS program. NSS is a
> very bad design. An ongoing issue we're working on addressing in musl
> is how to support alternate backends for other non-DNS things NSS
> provides -- mainly the user database -- without ugly hacks like
> putting them all in the libc. The eventual solution will probably be
> some sort of proxying daemon that speaks either NSCD protocol or a
> textual protocol that's nearly identical to the /etc/passwd format.

 We entirely agree here.

-- 
 Laurent