> 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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
