dns and software, was Re: Reliable Cloud host ?

Thu Mar 1 16:57:53 UTC 2012

Hi,

On Mar 1, 2012, at 7:22 AM, Joe Greco wrote:
> On Mar 1, 2012, at 7:01 AM, Michael Thomas wrote:
>> 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.

I always thought the right way to deal with IPv6 would have been to use a 32-bit number from the class E space as a 'network handle' where the actual address (be it IPv4 or IPv6) was handled by the kernel. I suspect this would have allowed the majority of network-utilizing applications to magically just work, regardless of whether the name supplied by gethosbyname/getnameinfo/etc. was mapped to an address with A or AAAA. Probably would make stuff faster too since you'd only have to deal with an unsigned int instead of (worst case) 16 bytes that have to be copied back and forth.

Instead, we have forced application developers to use a really odd mixture of old and new, e.g. 'struct sockaddr_in6' and GNI/GAI.  Seems this is the worst of both worlds -- no backwards compatibility yet an adherence to a really broken model that requires applications to know useless details like the length of an address ("what do you mean a sizeof(struct sockaddr) isn't big enough to hold an IPv6 address?") and even its bit patterns.

>> 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.

>> and
>> most likely causes even more trouble: what if I want, say, asynchronous
>> name resolution?

Set non-blocking on the socket?

>> 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.

>> 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)).

> It's deeper than just that, though.  The whole paradigm is messy, from
> the point of view of someone who just wants to get stuff done.  The

> examples are (almost?) all fatally flawed.  The code that actually gets
> at least some of it right ends up being too complex and too hard for
> people to understand why things are done the way they are.

Exactly.  Even before IPv6, it was icky.  Now, it's just crazy. We had an opportunity to fix this with IPv6 since IPv6 required non-trivial kernel hackage.  Unfortunately, we didn't take advantage of that opportunity.

Regards,
-drc