dns and software, was Re: Reliable Cloud host ?

Thu Mar 1 18:00:17 UTC 2012

On 03/01/2012 08:57 AM, David Conrad wrote:
>
>> Moving it across the kernel boundary solves nothing
> Actually, it does.  Right now, applications effectively cache the address in their data space, requiring the application developer to go to quite a bit of work to deal with the address changing (or, far more typically, just pretend addresses never change). This has a lot of unfortunate side effects.

My rule of thumb is for this sort of thing "does it *require* kernel level access?"
In this case, the answer is manifestly "no". As far as ttl's go in particular, most
apps would work perfectly well always doing real DNS socket IO to a local resolver
each time which has the side effect that it would honor ttl, as well as benefiting
from cross process caching. It could be done in the kernel, but it would be introducing
a *lot* of complexity and inflexibility.

Even if you did want super high performance local DNS resolution, there are
still a lot of other ways to achieve that besides jamming it into the kernel. A
lot of the beauty of UNIX is that the kernel system interface is simple... dragging
more into the kernel is aesthetically wrong.

>>> What if I want to use SRV records? What if a new DNS
>>> RR comes around -- do i have do recompile the kernel?
> I believe with the exception of A/AAAA, RDATA is typically returned as either opaque (to the DNS) data blobs or names. This means the only stuff the kernel would need to deal with would be the A/AAAA lookups, everything else would be passed back as data, presumably via a new system call.

SRV records? This is starting to get really messy inside the kernel and for
no good reason that I can see.

>
>>> 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).
> There have been lower-level resolver APIs since (at least) BSD 4.3 (man resolver(3)).

This is all getting sort of hazy since it was 8 years ago, but yes res_XX existed,
and hence the ares_ analog that I used. Maybe all that's really needed for low
level access primitives is a merger of res_ and ares_... asynchronous resolution
is a fairly important feature for modern event loop like things. But I don't claim
to be a DNS wonk so it might be worse than that.

Mike