Subject: persistent domain names

From: Zefram <[email-masked]>
Date: Tue, 30 Oct 2001 21:15:35 +0000

Last week I published an I-D, draft-main-sane-tld-00, which argued that
there is a need in various Internet protocols for easily-available
persistent[1] names within the DNS domain name space.  I queried in
dnsop, which seemed the most relevant WG, concerning what would be the
appropriate place to discuss it.  The only consensus reached seems to
be that dnsop is not the right place, so I'm throwing this open to a
wider audience.

The debate in dnsop actually centred on whether this is an IETF matter
at all, rather than on which WG it is relevant to.  Some said that it's
not a technical problem -- it's true that it's not a technical problem
in the DNS protocol, it's a problem for other protocols.  There were
varying opinions on the extent to which ICANN is, or should be, involved.

So I'd like opinions from the wider IETF membership: is the problem my
I-D describes something that the IETF should be concerned about?  Is it
something that can be usefully discussed within the IETF?  And if so,
what is the proper forum?

I'm looking for discussion of the problem more than the solution at this
stage; my I-D does outline a couple of possible solutions, but considering
the issues that have arisen already in respect of the problem statement,
solution finding will have to wait a bit.

-zefram

[1] Persistent in the way that MIME types such as image/vnd.xiff are
persistent.

---

From: [email-masked]
Date: Tue, 30 Oct 2001 18:48:40 -0500

> solution finding will have to wait a bit.

Let's look at the major points:

DNSSEC - I re-read your draft several times, and I think what you're
trying to say is "DNSSEC authenticates the current value of the
mapping of 'www.foobar.com' to an A record", and doesn't address the
question of whether 'foobar.com' is the same company that you visited
2 months ago.  If so, you're correct in saying that it's working as
designed - DNSSEC is there to prove that the data you got is what
was actually sent out by the NS entry for the zone, and not modified
or forged en route.  The problem here is not DNSSEC, but unrealistic
expectations.

URI - we'll work with the ISSN example that you gave. Designing a DNS
that is fault-tolerant is well-understood (use multiple NS in different
AS, not all in the same /24 like certain famous sites did ;).  Therefor,
for this discussion, "if issn.org goes away that URN space is hosed".
Very true - but let's think a bit deeper.  "issn.org" is not likely
to go away unless the ISSN International Centre goes away - in which case
the ISSN system is in trouble anyhow.

A6 addresses - There's absolutely nothing new here, as this is the same
issue as has *always* existed whenever you contract DNS services to
a provider. "The NS entry has to point to a nameserver".  A little thought
would show that in fact, you do *NOT* necessarily want persistent names,
what you want is *continuous service*.  (Hint - think why CNAMEs exist
in the DNS at all...)

domain names in certificates, etc - That's what a CRL is for.
In addition, keeping a "fingerprint" of a certificate in order to verify
you're talking to the same entity as last time is a good approach.
The concept of "persistent" is probably a *bad* idea here - what if
"microsoft.com" had been persistent, and the Dept of Justice *had*
managed to force a breakup into 2 or 3 separate entities?

You then argue for the creation of a 'tech' domain, although this does
absolutely nothing for the DNSSEC and A6 address issue.  In 4.4.7 you
discuss namespace bloat, but it's unclear whether 

   the enormous size of the current gTLDs is largely attributable to
   many organisations registering huge numbers of domain names each.

is actually true or not.  Are there numbers to back this up?  I thought
a large part of the bloat was due to everybody who has a web browser and
$15 to spare registering 'joes-pet-frogs-irving-and-thaddeus.com'.

Trying to make the namespace more heirarchical has hazards - see the .US
domain for an object lesson.

Section 4.4.8 asks if "some attempt to make domain names resemble
organisations' common names".  This is a Very Bad Idea, because *that*
was what led to the trademark wars mentioned in 4.4.6.

The discussion of MIME types is a total red herring.  Count the number
of registered vnd.* MIME subtypes, and compare that to the number of
*.COM domains.  And the vnd.* system has the same problem as the ISSN
example - if the "responsible organization" goes away, you end up with
a crufty registry.

And therein lies the basic problem - you say "persistent the same
way that image/vnd.xiff is persistent" - while glossing over the
fact that the 'xiff' registry is not *truly* permanent either.

To be sure, there *are* some major issues:

1) Totally broken conflict resolution for trademark disputes.
2) identifying that a given domain is in fact still the same one.
3) User expectations.
4) Some protocols *do* expect a long-term stable definition.

Most of these issues are already addressable with current technology,
and the proper choice for the rest is *not* to try to mandate persistent
identifiers, but to think about ways to design things that don't break.

Consider the DNS Survey (http://www.isc.org/ds/) - it was being
run every 6 months, and taking multiple weeks to complete.  And the Internet
was growing fast enough that there was a measurable delta *while the
survey ran*.  

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Oct 2001 22:14:10 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Zefram" == Zefram  <[email-masked]> writes:
    Zefram> Last week I published an I-D, draft-main-sane-tld-00, which
    Zefram> argued that there is a need in various Internet protocols for

  I'll read your draft, which I have not yet done.

    Zefram> The debate in dnsop actually centred on whether this is an IETF
    Zefram> matter at all, rather than on which WG it is relevant to.  Some
    Zefram> said that it's not a technical problem -- it's true that it's not
    Zefram> a technical problem in the DNS protocol, it's a problem for other
    Zefram> protocols.  There were varying opinions on the extent to which
    Zefram> ICANN is, or should be, involved.

  I would generally agree that the issues are mostly political.
  There are various dynamic DNS systems out there, many are now switching
to DNS update protocol from the various UDP based hacks that were out there.

  The opportunistic encryption draft
      (draft-richardson-ipsec-opportunistic-02.txt)

  relies on ability of users' to populate the reverse DNS maps (and
then to secure it with DNSSEC). The major obstucle is the "IPtelcos"/CableCos
who aren't being very retinscent to actually let people being peers rather
than just client-consumers. There is, with dynamic DNS update no reason why
they should not permit people with "always-on" IPs to populate the reverse
DNS.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 09:13:04 -0500

> the ISSN system is in trouble anyhow.

Woaaaaaah... I think there's a huge misunderstanding of the URI Resolution
process here.  Cutting out the original document's discussion here:

<paste>
2.2 URI Resolution

   The URI resolution process defined by [NAPTR] refers URI resolvers
   through a series of domain names to route a resolution request to the
   appropriate authority that can give a location or other information
   for a resource.  These referrals, being by name, implicitly assume
   that the name/identity mapping is persistent.

   In particular, consider URN types that are managed and resolved by a
   single organisation, for example the "ISSN" URN namespace described
   in [ISSN-URN].  In cases like this, resources critical to the
   handling of all URIs of a particular type are named within a domain
   managed by the single organisation responsible for that URI type.
   Any interruption of name resolution in that domain, or any compromise
   of the name/identity correspondence for that domain, would be highly
   disruptive.  It is necessary in these cases that the name of a
   privately-managed domain be reliably persistent.
</paste>

The referrals are meant to be dynamic. That's the entire point of
the URI Resolution process. If issn.org becomes disrupted either
through some DNS problems or through the fact that ISSN changes
their dns entries to be ISSSSSN.info or somesuch, the URI Resolution
process still works if you do the delegation the way the documents
suggest you do it. The ISSN organization could setup their NAPTR resolution
process so that every day at 4:00 the delegation through (not to, but
through) issn.org gets changed to some other domain-name. The
entire process is dynamic enough using DNS' TTLs that there is no
need for the domain-names to be persistent. The only one that does have
to be persistent is the very first one (uri.arpa).

In that one small sense, you are right. We do need some domains to be
persistent.  But we already have a process for doing that in the .arpa domain.
But it should be done _EXTREMELY_ carefully. Persistence in the DNS is
just the wrong way of going about it. Make your URIs persistently bound
to the logical Resource and then use some dynamic resolution
mechanism to make sure you can keep that resolution step in line with the
logical binding....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 09:17:34 -0500

> solution finding will have to wait a bit.

BTW, If you want to use OIDs in URIs there's already RFC 3061. The only
problem is with resolution since there is no OID database and proving
who has what is not a simple operation at all...

-MM

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 31 Oct 2001 13:51:50 -0500

At 22:14 30/10/01, Michael Richardson wrote:
>The major obstucle is the "IPtelcos"/CableCos

        Secure Dynamic DNS Update does not actually work 
operationally in most deployed DNS systems, so I don't 
think that such an approach is operationally feasible
today.

        Details of how/why Secure Dynamic DNS Update is
problematic are best discussed on a mailing list devoted
to DNSsec, IMHO.

Ran
[email-masked]