nanog mailing list archives
Re: dns and software, was Re: Reliable Cloud host ?
From: Michael Thomas <mike () mtcc com>
Date: Thu, 01 Mar 2012 10:00:17 -0800
On 03/01/2012 08:57 AM, David Conrad wrote:
Moving it across the kernel boundary solves nothingActually, 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
Current thread:
- Re: dns and software, was Re: Reliable Cloud host ? Tim Franklin (Mar 01)
- <Possible follow-ups>
- Re: dns and software, was Re: Reliable Cloud host ? Owen DeLong (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? William Herrin (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Michael Thomas (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Joe Greco (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Michael Thomas (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? David Conrad (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Jeroen Massar (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? David Conrad (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Michael Thomas (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? David Conrad (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? William Herrin (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Owen DeLong (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Mark Andrews (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? William Herrin (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Mark Andrews (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Owen DeLong (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? William Herrin (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Chuck Anderson (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? Owen DeLong (Mar 01)
- Re: dns and software, was Re: Reliable Cloud host ? William Herrin (Mar 01)