Subject: RE: utility of dynamic DNS

From: "Peter Ford" <[email-masked]>
Date: Mon, 4 Mar 2002 09:06:58 -0800

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. 

I will not argue against the fact that IP addresses have the nice
property that when a host A tells another host B its address (as the src
address of an IP packet) that host A is reachable by that address.  I
would argue that property is not persistence, it is temporally bounded
reachability (TBR - we can have a bof to get a better name).

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?  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?   Is this what
we are supposed to use as evidence that IP addresses are more persistent
than DNS names?

And when those hosts connect to the Internet, what do they use FIRST
when they want to communicate with a peer?   (now I have opened the dam
here, haven't I?   Strictly speaking they will use the IP address of "."
to get going!  Mcast DNS can fix that bug.).

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.  And I am also arguing that you can
get "good enough" roaming if you use DNS names.   

And I am asking whether anyone can actually prove that DDNS is not
scalable (preferably for real Internet applications and uses).

Regards, peter

(P.S.  And shouldn't you be asking:  "Peter, if you really want hosts to
register their tunnel ends in the DNS, isn't the most likely
implementation one where the host gets a persistent IP address, and gets
many TBR IP addresses over time?" - cheers, peter)

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Friday, March 01, 2002 8:25 PM
To: Peter Ford
Cc: Geoff Huston; [email-masked]
Subject: Re: utility of dynamic DNS 

> I would offer that we select the "thing" that looks the most
persistent
> to be the persistent identity.  

Actually, you want to select the identity  that's appropriate for your
purpose.  DNS is not inherently better than IP for all purposes.
DNS names are often failure-prone, slow to lookup, and/or out of 
sync with reality.  

> If the choices are: DNS name vs IP address, I think most people would 
> recognize that the DNS name is the persistent identity.   

And if 'most people' treated this as a general rule, they'd be wrong.
There are several situations where IP addresses are more usable
than DNS - the DNS name may not even exist, lookups may not work
outside of a realm, or the name may be bound to an IP address rather 
than a host.  It is highly dependent on the configuration of the network
where the hosts are located and the DNS servers that serve them.

See draft-moore-nat-tolerance-recommendations-00 for a more detailed
explanation.

> We should probably try to move the debate from "proof by emphatic
> assertion" to analysis.

Presumably that also applies to assertions about persistence of DNS
names.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 Mar 2002 13:06:42 -0500

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

> an IP address?  

dialup connectivity does not imply long periods of disconnection.

> And what about those hosts that have DNS names inside
> 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.  

> 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