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
