IPv4 address length technical design

Cutler James R james.cutler at consultant.com
Sat Oct 6 20:08:04 UTC 2012


On Oct 6, 2012, at 2:35 PM, Barry Shein <bzs at 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. 


More information about the NANOG mailing list