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
