Fred Baker wrote: > What would be Really Nice would be to in some way ensure that > applications never saw IP addresses at all - they *only* worked on > names, and maintained no knowledge in the application of what address > was used. To my small mind, forcing a new DNS lookup in the event of a > TCP session failure and restart would be a good thing. perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts.
in other words, doing another DNS lookup of the original DNS name only looks like a good way to solve the problem if you don't look very deep. now if you somehow got a host-specific (or narrower) identifier as a result of setting up the initial connection (maybe via a TCP option), and you had a way to map that host-specific identifer to its current IP address (assume for now that you're using DNS, though there are still other problems with that) - then you could do a different kind of lookup to get the new IP address and use that to do a restart. even then, it wouldn't help the numerous applications which don't have a way to cleanly recover from dropped TCP connections. (remember, TCP was supposed to make sure data were retransmitted as necessary and that duplicated data were sorted out, provide a clean close, that sort of thing. once you expect apps to handle dropped connections they have to re-implement TCP functionality at a higher layer.) > The authors of RFC 4778 would take exception - they want to be able to > log into the right place when everything is in flames. Apart from > that, though, managing addresses through names would go a *long* way > toward making renumbering easier. We already have many of those > capabilities, though. We have to as an industry consistently use them > that way. and yet, it's quite clear that DNS as it currently exists is not adequate for this. not the query protocol, nor the data caching model, nor the APIs, nor the security (at least as deployed), nor the names that we're currently using, and probably not even the replication mechanism. which might be why the industry hasn't started consistently using DNS for this. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
