On Tue, 30 Oct 2001 21:15:35 GMT, Zefram <[EMAIL PROTECTED]> said: > 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.
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
