nanog mailing list archives

Re: dns and software, was Re: Reliable Cloud host ?


From: Michael Thomas <mike () mtcc com>
Date: Thu, 01 Mar 2012 07:01:16 -0800

On 03/01/2012 06:26 AM, William Herrin wrote:
On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong<owen () delong com>  wrote:
The simpler approach and perfectly viable without mucking
up what is already implemented and working:

Don't keep returns from GAI/GNI around longer than it takes
to cycle through your connect() loop immediately after the GAI/GNI call.
The even simpler approach: create an AF_NAME with a sockaddr struct
that contains a hostname instead of an IPvX address. Then let
connect() figure out the details of caching, TTLs, protocol and
address selection, etc.  Such a connect() could even support a revised
TCP stack which is able to retry with the other addresses at the first
subsecond timeout rather than camping on each address in sequence for
the typical system default of two minutes.

The effect of what you're recommending is to move all of this
into the kernel, and in the process greatly expand its scope. Also:
even if you did this, you'd be saddled with the same problem because
nothing existing would use an AF_NAME.

The real issue is that gethostbyxxx has been inadequate for a very
long time. Moving it across the kernel boundary solves nothing and
most likely causes even more trouble: what if I want, say, asynchronous
name resolution? What if I want to use SRV records? What if a new DNS
RR comes around -- do i have do recompile the kernel? It's for these
reasons and probably a whole lot more that connect just confuses the
actual issues.

When I was writing the first version of DKIM I used a library that I scraped
off the net called ARES. It worked adequately for me, but the most notable
thing was the very fact that I had to scrape it off the net at all. As far as
I could tell, standard distos don't have libraries with lower level access to
DNS (in my case, it needed to not block). Before positing a super-deluxe
gethostbyxx that does addresses picking, etc, etc, it would be better to
lobby all of the distos to settle on a decomposed resolver library from
which that and more could be built.

Mike


Current thread: