> Keith, > > I did not argue the persistence of ALL DNS names. > > What I did argue is that if I was trying to tell someone how to reach a > particular Internet based service I would write down something that had > a DNS name in it, not something that contained an IP address. For me, > that is a measure of persistence. indeed, DNS is the better kind of name to use for the case where you're providing a referral that is going to be used at some indefinite time in the future, to a service with a relatively stable IP address that also happens to have a stable DNS name. and if you have a stable IP address the barrier to getting a DNS name is low enough that most services that have a relatively stable IP address probably do have a stable DNS name. in this case, using the DNS name will insulate you against the occasional change of IP address. DDNS is useful to keep DNS updated across occasional changes in IP address. but it doesn't solve the problem of applications that break when the IP address changes, nor does it solve the problem where there's a need to (re-)connect to a particular process on a particular host but the a DNS name for a service doesn't uniquely refer to a single end system. that's one reason that the DNS name is not inherently a more reliable identifier to use in all kinds of referrals. in a nutshell: IP addresses are often better at providing short-term persistence than DNS names. URNs are an attempt to provide long-term persistence, because DNS names were not felt to be sufficiently stable over long periods of time. DNS names provide medium-term persistence - usually good enough for next week or next month or maybe next year, not necessarily good enough for a few seconds or minutes from now, nor for decades from now. (the assumption here is that an application that needs to provide referrals for much later will not put critical state in short-lived storage that can only be directly accessed by one process - it will replicate that state and/or make it more widely accessible. OTOH if the referral is only needed to be valid a short time in the future then it is more reasonable for an app to make that state accessible to only a single process and to require that other components contact *that process* in order to interact with that bit of state.) > Now, let's look at most of the systems that you refer to that do not > have a DNS name. How many of those hosts connect to the Internet using > dialup connectivity and for the better part of the day do not even have > an IP address? dialup connectivity does not imply long periods of disconnection. > And what about those hosts that have DNS names inside > their corporate networks, but their corporations elect not to publish > those persistent names into the DNS for security fears? that is a subset of hosts for which DNS names may be less reliable than IP addresses. just because the DNS names aren't visible or usable outside of some realm doesn't mean that the enterprise doesn't want to run applications that are used in other environments where different rules apply. > I am not suggesting that all hosts solely use DNS names as a rule. I > will suggest if you want to advertise services and hosts then use DNS > names because that is what works. your use of the word "service" carries some assumptions with it - e.g. that the process you wish to connect to has a long-term stable presence, that it is designed to be generally accessible (modulo permissions), etc. not all processes that wish to receive traffic fit this model. > And I am also arguing that you can get "good enough" roaming if you > use DNS names. generally speaking, it's "good enough" to run applications that were designed with disconnected operation in mind. not all applications fit this pattern. Keith