nanog mailing list archives

Re: dns and software, was Re: Reliable Cloud host ?


From: David Conrad <drc () virtualized org>
Date: Thu, 1 Mar 2012 08:57:53 -0800

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



Current thread: