draft-iab-unique-dns-root-00.txt
Richard J. Sexton
> The above document is on the IESG table for publication as Informational.
> Could some of you pls take a quick look at it and let me know if you
> see any trouble with it? Preferably before Thursd 5pm my time
> (Central European Time).
Here's what I sent... (I have worked with Bert Wijnen in the past on a
number of network management related matters.)
--karl--
>From ka...@CaveBear.com Wed Feb 23 09:56:39 2000
Date: Wed, 23 Feb 2000 09:53:04 -0800 (PST)
From: Karl Auerbach <ka...@CaveBear.com>
To: Bert Wijnen <WIJ...@VNET.IBM.COM>
Subject: Re draft-iab-unique-dns-root-00.txt
This was just forwarded to me...
> The above document is on the IESG table for publication as Informational.
> Could some of you pls take a quick look at it and let me know if you
> see any trouble with it? Preferably before Thursd 5pm my time
> (Central European Time).
I have substantial trouble with that draft.
While there are some mild technical problems that can arise if there are
multiple root systems in use, the draft goes far beyond and makes claims
that go beyond being simply technical and are really policy choices
regarding how one might use the Internet.
The technical problems arise in the context of zone files that contain
certain kinds of records, usually NS and CNAME records, that use domain
names as the record data. Those names in the records might reference top
level domains that do not exist, or may exist differently in a differnent
root system. This amounts to incorporating by reference something over
which one has no control, that's usually a questionable practice in any
context, not just DNS.
This can be handled by the person writing the zone file simply being
careful about such references beyond the zone itself.
This is a technical problem that, if it rises to be a concern that the net
might be "damaged", is something that ought to be repaired by changing the
protocols Since it is a situation that can be caused by any kid on the net
setting up a root system banning the practice is likely to be futile.
Indeed, we're seeing such root systems being established professionally as
the result of impatience with the lack of internationalized domain names.
The bigger issue with the draft are its sweeping statement that names
must be universal else references will fail.
First off, in real life references fail continuously - people send URLs
pointing to web pages behind firewalls, to pages that are password
protected, to files that have been removed, to files that have been
replaced with distinctly different material, or to hosts that have been
decommissioned.
If the stability of DNS names is so important, then I submit that the loss
of reference ability is far more at risk due to the above factors than to
the existance of multiple competing DNS root systems.
E-mail addresses suffer the same fate. By the logic of the draft, we
ought to not allow e-mail addresses to change or be discontinued.
The draft is concerned about the potential for a person to reach a "wrong
number". "Wrong numbers" can occur just as readily with a single DNS root
as they can with multiple DNS roots. I suggest that the technical approach
to this issue is authentication.
There are a number of arguments why having competing systems of
roots would be a good thing. See my rather old note at:
http://www.cavebear.com/cavebear/growl/issue_2.htm#multiple_roots
One of the main assertions of that note is that the feared growth of
disjoint naming systems is unlikely to occur - just as it is possible for
the publishers of all the different kinds of telephone directories to come
up with flawed name-to-number mappings, it doesn't happen in real-life
because the books from the flawed publisher are corrected else the users
learn to distrust that publisher and will take their name lookup needs
to another publisher.
When it comes down to the bottom, the main difference I have with the
draft is that I believe that the fundamental service of the net is the
delivery of IP packets. I believe that the matter of turning DNS names
(or URLs) into addresses (or other kinds of records) is a service that the
user ought to be able to pick and chose from any of a number of providers.
If a user finds that the service he/she is using doesn't do a decent job,
then that user can switch to a better service.
I note in passing that nearly all of us have hosts files and many of us
have things like "junkbusters". These, in their own ways, supersede DNS
and give tailored views of the net name spaces. Similarly, with the rise
of things such as Doubleclick and user-tailored content, a web referencing
URL gives different results depending on who is uttering it. And as
"directors" are deployed across ingress/egress points, DNS name munging in
URLs will become ever more common.
Finally, the draft and I differ on who would be "harmed" by multiple DNS
root system. If one choses to publish one's net presence using a top
level domain that exists in only a few of the root systems, the harm is to
that person. The users of the net who can't reach such a publisher can't
complain - they have no "right" to the material, they are merely the
distant beneficiaries of the publisher's voluntary decision to publish the
material in the first instant.
--karl--
--
Richard Sexton | ric...@tangled.web | http://dns.vrx.net/tech/rootzone
http://killifish.vrx.net http://www.mbz.org http://www.dnso.com
Bannockburn, Ontario, Canada, 70 & 72 280SE, 83 300SD +1 (613) 473-1719
Jim Kingdon
can come up with an RFC which presents the pros and cons of both
alternatives (a la RFC1918), or two different RFC's can be written and
published (a la RFC1597 and RFC1627).
Karl Auerbach's message was pretty good, although he doesn't address
cache pollution which is referred to (sort of in passing) by the text
"The client will simply return the first set of resource records that
it finds that matches the requested domain, and assume that these are
valid" in draft-iab-unique-dns-root-00.txt.
Parts of draft-iab-unique-dns-root-00.txt are good, like "Difficulty
of Relocating the Root Zone" (which doesn't imply that there be
exactly one root, but which does correctly point out the desirability
of good coordination within the primaries and secondaries of a given
root, including anything which was a primary or secondary in the
past).
And for those who don't know what we're talking about, internet drafts
are at ftp://ftp.ietf.org/internet-drafts and
http://www.ietf.org/internet-drafts/
I also stumbled across
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-root-opreq-03.txt
which is an updated RFC2010. This one (although it mentions policy
issues in passing, like 2010) does a good job of keeping the
difference between technical and policy clear.
Richard J. Sexton
>cache pollution which is referred to (sort of in passing) by the text
I have a problem with this "cache pollution" stuff. It
seems to me to break down into two areas:
1) Returning the wrong address for, say, internic.net
2) Out of band data (do dig mbz.org ns @ns1.vrx.net)
The law deals with 1) quite adequatley IMHO.
As for 2) this is why Vixie invented the phrase. Historians
will note that Vixie was the only member of the Usenet Backbone Cabal
that thought alt was a truly bad ida and should be filtered out of
existance, and it was of course crossposting to regular
usenet that popularized alt.
Fwiw, I read 4 non-usenet II groups: comp.protocols.tcp-ip.domains,
alt.horology, alt.auto.mercedes and alt.aquaria.killies.
While there are a lot of stupid alt groups, the three mentioned
above are quite good, while the comp one is getting rather
sewer like. My opinion is that alt has served a very useful
purpose and allows meaningful communication outside the
jurisdiction of the tight asses of this world; if people
had listened to Vixie it would never exist.
Jim Kingdon
Not sure what part of the result you are trying to call attention to,
but one of the results is
lighting.faq. 172800 A 199.166.24.135
Now suppose someone then queries ns1.vrx.net, and their name server
believes the entry for lighting.faq. Now suppose there is another
record (reached from a different root) which points lighting.faq at
another IP address. Then which address you get for lighting.faq
depends on which nameserver you query first and whether the cache has
timed out and so on, which is a Bad Thing. The Right Thing is for a
nameserver to just believe lighting.faq RRs from a server which has
the right to set them for that domain (ultimately based on which
roots are configured). At least, I think so.
As far as I know, this kind of thing is solvable. But the whole point
of writing an RFC would be to go into a fair amount of detail along
the lines which I outline in the above paragraph.
> Historians will note that Vixie was the only member of the Usenet
> Backbone Cabal that thought alt was a truly bad ida
Shrug. Vixie is indeed too much of a control freak for my tastes.
But on the whole I'm glad to have him around - he is one of the forces
that keeps the "spirit of the internet" (whatever that is) alive.
Partly because people rarely listen to him unconditionally.
Richard J. Sexton
Jim Kingdon <kin...@panix.com> wrote:
>> 2) Out of band data (do dig mbz.org ns @ns1.vrx.net)
>
>Not sure what part of the result you are trying to call attention to,
>but one of the results is
>
> lighting.faq. 172800 A 199.166.24.135
>
>Now suppose someone then queries ns1.vrx.net, and their name server
>believes the entry for lighting.faq. Now suppose there is another
>record (reached from a different root) which points lighting.faq at
There isn't. That's like saying "what happens if I get hit by
a comet".
If somebody else deplots .faq then I'll do as RFC 1591 says and
settle that dispute with *them*. In general there are no
tld disputes apart from CORE's intentional fuckup with .web
which is beng settles as we speak.
If somebody else stuicks in an A record for lighting.faq
then they're in violoaiton of RFC1591 "first come, first
served".
>Shrug. Vixie is indeed too much of a control freak for my tastes.
>But on the whole I'm glad to have him around - he is one of the forces
>that keeps the "spirit of the internet" (whatever that is) alive.
>Partly because people rarely listen to him unconditionally.
Spare me.