[dns-operations] To A or to AAAA - was Re: Signaling client

[Edward Lewis]

At 11:49 -0800 1/17/11, Doug Barton wrote:

(If you thought my last post was long, wait till you skip this one...)

>The right answer here _is_ actually to fix applications (and OS') to not ask
>for address records that they cannot use.

Doug's on the right path, but I think the answer is a little further on.

First, this isn't a problem that can be treated with the DNS.  The 
DNS can be an ingredient in a solution, but at a cost.  (Meaning, 
using "tailored to the query responses" is possible but costs more to 
accomplish when compared to flat repetition of what can be passed 
around in AXFR messages.)

I would restate Doug's "right answer" to be - fix applications (which 
includes OS') to ask for all possible means to reach a resource and 
then try all possible means until a working one is found.

I began network application programming in the mid 80's and had the 
luxury of being a school mate of Chris Torek who was one of the chief 
developers of BSD sockets if not "the guy" who developed it.  (Never 
was clear on that, in those days no one looked to hold "titles.")  I 
learned a lot about the psyche of network programming from his work 
and from him during phone calls. Particularly enlightening were the 
ideological mistakes made in developing the model that has come to be 
what we know as BSD sockets.

There was this concept called "File/Device Independence."  Whether 
writing to a file in a file system or a hardware device, the API to 
the application was to present the same look and feel.  Preceding the 
network was the file system, so the sockets interface was bent into 
shape to try to make the network look like a file system.  The 
problem was, this was a shoe-horning in the wrong direction.  (Today 
we know that the file system is a degenerate form of a network 
system.)

If a file system died, meaning that while the file you were writing 
to was on a disk that blew it's top, the OS would come to a stop at 
some point (there were larger problems) so it wasn't worth "saving" 
an application.  What this meant was there was little reason to 
include rich error feedback features in sockets.

If you ever tried to write a non-blocking connect call and had to 
tell when the connection was open for writing, you would know what I 
mean.  The trick was to do a read() call for 0 bytes to determine 
when there was data pending that wasn't an EoF.  It made little sense 
- you want to write() but you need to do a read().  Furthermore, API 
vendors (TGVmultinet for one) thought that asking for 0 bytes in a 
read() was a "mistake" and wouldn't run the error check.

As a second example, try to make head or tails of the select() call 
in asynchronous situations (before threading was invented).  The 
select() call is computing's version of the duckbilled platypus.

The reason for this long story was that I see this as a basis of why 
network applications have so poorly dealt with unexpected network 
behavior over the decades.  The failure in the early years to include 
adequate error feedback engendered a few generations of programmers 
that didn't know how to write for adversity.  I used to use the 
analogy of taking a class of high schoolers, breaking one of the legs 
and setting it off 90 degrees to the side and then trying to teach 
them to run around an oval track.

It's because of this we have a lot of sissy applications that can't 
handle a choice of paths to a destination.

Chapter 2

When I taught some coders in the 90's I suggested asking for a 
service two ways simultaneously, such as trying to connect to a v4 
address and to a v6 address.  I was told that an application couldn't 
then handle the situation when more than one of the requests 
succeeded.  I found this incredulous.  You're lucky if there's more 
than one success path - and you have the luxury of killing one off 
and/or keeping it around as a fallback.  I'm sure today's programmers 
(especially those on this list) are more astute.

If I were to design an application today, I'd always have some sort 
of handshake once the session began, to make sure the other end is 
speaking the right protocol, and perhaps to decide "how well."

Summary

The reason for this rambling tirade is that Doug's part right but 
falls short when it gets to determining "address records they cannot 
use."  That's impossible to "compute".  I might have a v6 set up in 
my house but be on a ISP that can route me to f.root-server.net/AAAA 
but not m.root-servers.net/AAAA (I've seen this).  An application 
can't possibly know a priori to ask for f's AAAA and not m's AAAA. 
Trying both will tell me, but not until I try.

Applications need to be more aggressive and rugged in trying to reach 
whatever they want off the 'net.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Jan 11, 2011 - Either it's 1/11/11 or 11/1/11,  "Junior Saint Broadcast day"
(Nov 11 is senior...)