[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wg-b] RE: [wg-c] IAB Technical Comment on the Unique DNS Root
(I'm not on WG-B, but on WG-C, hence I moved my response to WG-C. The
importance in WG-C is that there ought to be a sensitivity that if no new
TLDs are added soon, there could readily arise sufficient pressure to turn
competitive roots from the rare and limited thing they are today into
something more mainstream. And that would obviate much of ICANN and its
decisions.)
> If MHSC adds a domain to their "roots", and another competitor adds a
> domain to their "root" with the same name but different content, the result
> is architecturally unsound - or to put it another way: It does not work.
I very much perceive this like the Catholic church telling Galileo that
the planets don't orbit yet he knew, by what his own eyes had observed,
that they do.
Various folks can believe that there is and must be but one glorious root
system and that there must be for all time and all things a single,
unified way of naming things on the Internet.
I don't agree with that.
From my point of view a naming service is just that, a service, something
I can use or not use at my option. And it is a service that is amenible
to competitive activity from various providers who package their offerings
in different ways and have different flavors of offerings.
The simple fact of the matter is that the DNS system works reasonably well
- in my observation, more than reasonably well - if there a multiplicity
of portals (root systems) through which people reach the TLD servers.
There are those who focus on the problem that I may say "send me e-mail at
karl@cavebear.web" and that many, indeed most, folks aren't going to be
able to do it. I consider that to be a transitional issue and recognize,
in addition, that competitive roots will always allow the existance of
groups that can't name one another. That latter I find no more disturbing
than the fact that people often lose their e-mail addresses when they
change jobs of switch ISP's.
If the DNS system, or its various implementations, can be damaged by
something that any 13 year old kid can do using freely available software,
and without violating any network security, then I submit that there is a
design or implementation flaw.
And if one does accept the axiom (which I do not) that there be one
uniform name system, then one really does have to ask, why ICANN's? Why
not some other that might be operated and staffed by paid professionals
rather than by volunteers? (Not that professionals are automatically
better than volunteers, often they aren't.)
I've read the IAB statement and to my eyes/ears it sounds exactly like
what my local vegans (ultra strict vegetarians) say about eating meat -
that it is bad - wrapping what is essentially a quasi religious point of
view in scientific language - and ignorring the fact that a lot of us are
happy being carnivores and aren't going to stop.
As a practical matter, nobody can stop competitive roots from arising. And
if somebody with some money gets involved and does some creative
marketing, or if WG-C slams the door on new TLDs and TLD operators,
then competitive roots could even become viable alternatives to ICANN.
From the point of view of communities that want to restrict what they or
their children see of the net, controlling their own name space is an
atractive thing. (Indeed, in my own area any web reference to things like
"doubleclick.com" end up being mapped into a web server that returns a
single point transparent GIF.) And the IETF-censored e-mail list is an
example of a voluntary limitation on communication.
And from the point of view of ISPs that want to avoid the conveyance of
the current significant load of DNS traffic across their increasingly
paid-for exchange borders, having a localized DNS root and mirrored local
servers can save a lot of money and improve response times.
To add a bit more complexity, there are boxes built by several companies
that can catch DNS queries, formulate answers based on personal profiles
of the person originating the query or based upon net and server load
measurements, and returning a personalized DNS response. These devices
break, often for very good reasons, the end-to-end principle that
underlies the IAB statement.
And to top it off, ICANN's rules (e.g. UDRP) and taxes ($1/registration)
are expensive and are a competitive burden. Since competitive root
systems won't necessarily be imposing those same burdens, there is
actually a potential competitive advantage that they may have over ICANN.
As far as I can tell, the IAB's statement says "not being able to
communicate" is a bad thing. I agree with that. But I don't take the
Procrustean next step of mandating that everybody adhere to a single name
system. Because that path leads to permanent e-mail addresses that never
change, permant URLs that never change, no load balancing among web
servers etc etc.
<mild technical content>
The problems in DNS operation itself that I have observed are with NS and
CNAME records in which the author of the zone file has a perception of a
given TLD that is different from that of the user of that record. In
other words this only arises when there are divergent forms of the same
character string TLD label, such as two forms of .web.
With regard to that - given the pace of WG-C, it is unlikely that ICANN
will ever adopt any additional TLDs and thus this problem won't arise for
those who use the ICANN franchised root system. Even if they receive DNS
names (via URL or e-mail or whatever) containing contested TLDs, those
names will not resolve for those who stay in ICANN-land.
But assuming that contested TLDs do arise and that those who operate root
systems incorporate different versions of those TLDs into their offerings
(something that I personally would not do as those would represent sources
of calls to my support number and hence an undue expense.) -- Anyway,
assuming that this happens: Then what is the damage to DNS? It gets down
to that "additional" information part of the DNS response. If NS and
CNAME records were returned simply as strings and the querying resolver
was forced to then take over, there would be no harm to the data in the
resolver. The difficulty arises when there is "additional" information
that would be different depending on root system used. And, as it turns
out, this can only happen for information for which the server is
returning "additional" information for which it is not authoritative.
</mild technical content>
--karl--