Hi Bill,
|> 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. | |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. True, I should have said for each connection... |Doing a lookup for every packet would be asinine. But that's no reason to be rude about it. |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. Good point. |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. The issue, IMHO, isn't the delay, it's the scalability, especially in front of hot spots like Google. In these cases, it would make sense to have a hybrid mapping, where we can install full mappings at hot spots. Note that it's not exactly analogous, as hosts.txt (at least on some systems ;-) needed a manual update. This would be more equivalent to a mapping crawler, so that the cost would really be in the state being held. But, we again digress into mechanism. Tony -- 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
