Stig -
One solution, which is a bit of a kludge, could be to have some kind of interaction between DNS and the mapping system, where the necessary mappings can be installed (based on DNS replies), before the DNS reply is given to the application. [...]
Right, I had been thinking about this also. Few thoughts: - Piggybacking mapping records to DNS replies would enable pre-loading of an edge network's local mapping caches -- reactively, but still before the transport protocol launches its session and starts waiting for timeouts. - DNS-based mapping resolution does not imply per-address mappings; new DNS records may well describe mappings on an address-block basis. - DNS-based mapping resolution could be used in conjunction with another mapping system, as an optimization. One could leave it up to an edge network to decide whether or not to support the optimization by attaching mapping records to DNS replies generated by its DNS servers. - It may be unwise to rely *exclusively* on DNS-based mapping resolution because the technique does not work that well when a host starts a new session without an initial DNS look-up. In such a case, DNS-based mapping resolution would likely have to involve reverse DNS because the look-up key would not be an FQDN, but an identifier IP address. And this will be really costly in terms of delay. Comments are welcome. - Christian -- to unsubscribe send a message to rrg-request@psg.com 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