[PATCH] Make SRV/NS lookup routines async

[Jeremy Allison]

On Sat, Jan 12, 2019 at 10:37:37AM +0100, Volker Lendecke via samba-technical wrote:
> Hi!
> 
> Attached find a patch that provides basic infrastructure for fully
> async DNS lookups. The code as such is pretty small, the majority of
> this patchset extends our autobuild infrastructure to cope with that.
> The main one there is the idea of a central DNS server that just
> proxies DNS requests to the different real DNS servers that we run.
> With that in place, converting our SRV record lookup to routines that
> avoid the synchronous res_search & friends is simple.
> 
> This is just a start. The next steps will be to push asynchrony up the
> call chain, up to a point where dsgetdcname can be made fully async.
> 
> This is a case of NIH again. One way to go forward is to use c-ares.
> Why did I not go there directly? I had taken a look, but when I saw
> the ares_fds() routine I dismissed this completely as it seemed to
> depend on select(). Much later Jeremy told me that c-ares of course
> can live with poll. But at that point I was already pretty far down
> into our own routines.
> 
> The NIH syndrome is not as bad as it first looks: We need the
> marshalling routines in our code anyway, and we already have the basic
> DNS client code around for the AD DC DNS forwarder. Adding a simple
> resolv.conf reader is not really much work.
> 
> If we later decide to convert to a third party async DNS library,
> ripping out our own lookup routines is not months of work if all the
> callers are properly async.
> 
> Survived two private autobuilds.
> 
> Review appreciated!

Fantastic Volker, thanks a *LOT* for finishing this (I
saw the prototype :-).

This addresses a need that Google has seen as a Samba
OEM in ChromeOS (yes I know it doesn't cover the specific
issue ChromeOS had yet, but it moves us closer to contolling
out own destiny so we *can* fix it :-), and I'll review it
as soon as I'm back in at work on Monday.

Cheers,

	Jeremy.