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
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
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.