[150706] in North American Network Operators' Group
Re: dns and software, was Re: Reliable Cloud host ?
daemon@ATHENA.MIT.EDU (David Conrad)
Thu Mar 1 12:17:50 2012
From: David Conrad <drc@virtualized.org>
In-Reply-To: <201203011522.q21FM74H095011@aurora.sol.net>
Date: Thu, 1 Mar 2012 08:57:53 -0800
To: Joe Greco <jgreco@ns.sol.net>
Cc: Nanog <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
