On Fri, Jul 25, 2008 at 7:31 PM, Tony Li <[EMAIL PROTECTED]> wrote: > Fair. I think it's also fair to assert that the number of identifiers that > we need to support is linear with the number of hosts (and thus hostnames) > that we need to support. > > Further, we can assert that DNS supports mappings of this scale and does so > in a caching fashion. However, DNS is NOT invoked for anonymous > transactions and if it was, it would not scale appropriately. Imagine > Google doing a reverse DNS lookup on every packet it receives, for example. > > Do folks agree?
Tony, That's not an equivalent comparison for two reasons: 1. You don't do a lookup for every packet; you do a lookup for the first packet in a time-bounded series. That's true for both the query-cache map proposals and the DNS. Doing a lookup for every packet would be asinine. 2. Reverse-DNS lookups are often -much- less efficient that forward lookups. Hierarchy servers for forward lookups are typically held together with glue to in-scope servers, so they go fast. Reverse lookups are held together with servers from the forward hierarchies, so for each level you descend in the reverse hierarchy you have to go do a full traversal in the forward hierarchy to find the server address. That's an operations deficiency rather than a protocol deficiency. The reverse hierarchy could have been built with glue, but no one perceived a need. Despite that, you make a fair point. The counterargument is this: for virtually every packet google receives, the origin has already performed a DNS lookup in order to get that far. If the first-packet time is already slowed to DNS-time, what's the harm in a second lookup? Especially when the alternative is hosts.txt. There are counterexamples to that but they tend to cluster in three areas: 1. Local administrative access by IP address. That's out of scope here: the map-encap protocol is used on non-local situations. 2. Protocols like bit torrent where the remote IP address has been discovered through some other kind of lookup protocol. A mild lag in bit torrent's initial connect to a new peer makes no difference to anyone. 3. Worms hunting for machines to infect. No only don't we care if these are delayed, we'd prefer that they be delayed. Forever if possible. ;) Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
