> 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. We already have the DNS hooks to distingish services from hosts. We had them for the last 8 years. Some services actually use these hooks. > 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.) Applications need to deal with TCP connections breaking for all sorts of reasons. Renumbering should be a relatively infrequent event compared to all the other possible ways a TCP connection can fail. Until applications deal nicely with the other failure modes, complaints about renumbering causing problems at the application level are just noise. > > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf