nanog mailing list archives

Re: IPv4 address length technical design


From: Cutler James R <james.cutler () consultant com>
Date: Sat, 6 Oct 2012 16:08:04 -0400

On Oct 6, 2012, at 2:35 PM, Barry Shein <bzs () world std com> wrote, in part:

We can map from host names to ip addresses to routing actions, right?

So clearly they're not unrelated or independent variables. There's a
smooth function from hostname->ipaddr->routing.

I would suggest that this is a bit optimistic and oversimplified.  

The mapping between DNS names and IP addresses is not necessarily unique or commutative. One may change either 
arbitrarily, as long some "directory service" exists which contains the current mapping.  In addition, multiple DNS 
names may map to one or more IP addresses and IP addresses do not necessarily map to unique routes or DNS names. These 
are not smooth functions.

If names and addresses are not independent, then any change in either would predicate a change in the another.  That is 
apparently not the experience of most network providers.  The only action required for a change in network name or 
address is to update the "directory service" used to map between name and address.

Is this a good use of DNS computrons? Answering DNS inquiries for
every new connection for every single-routed host on the internet?

Yes, it is.  Most "new" connections are repeats of previous connections (I request mail from my IMAP servers several 
times each day) and the preponderance of caching resolvers make the effort and traffic trivial. Even in the absence of 
cached final DNS reply, putting the lookup burden on the end system rather than the "routing engines" should be a 
no-brainer.

In particular, adding caching of connection destinations within routing components would not only seriously burden 
(read, slow down) routing engines but is also a violation of the Stupid Network.  David S Isenberg said, "In a Stupid 
Network, control passes from the center to the edge".  See http://www.isen.com/papers/Dawnstupid.html, originally 
published as the cover story of ACM Networker 2.1, February/March 1998, pp. 24-31. 

Current thread: