Let IETF Do Net Naming.

I Find Karma (adam@cs.caltech.edu)
Thu, 22 May 97 17:09:13 PDT


[from the May 19, 1997 Web Week ... ]

> MOCKAPETRIS: I get misquoted a lot on this. I believe that there are no
> problems in expanding the TLD space that we couldn't solve in time. In
> fact, there may be no problems at all. But we don't know for sure, so I
> would favor adding a small number (say 20) to start, then maybe 100,
> then 1,000, etc., if you want to get to a very large number. I'm just
> being cautious in my old age.

There you have it, folks: the architect behind DNS sees nothing wrong
with the way DNS works.... Doh!

------------------- 8< ---------------------------------------------

IETF Should Have a Role in Names Dispute, Says DNS Architect
By Bill Semich

Ten years ago, while on the staff at the University of Southern
California's Information Sciences Institute (USC/ISI), Dr. Paul
Mockapetris developed today's Domain Naming System (DNS) for the
Internet. Only 200 domain names were in use at that time. Since then,
the Internet has grown to more than 20 million domain names, and has
become a major business and consumer activity.

Dr. Mockapetris has been chairman of the Internet Engineering Task Force
(IETF), the Internet's principal technical standards-setting body; chair
of the Internet Engineering Steering Group; a member of the Internet
Architecture Board; and program manager for networking in the Advanced
Research Projects Agency's Computing Systems Technology Office (ARPA
created the precursor of the Internet).

Today, Dr. Mockapetris is Chief Technology Officer at Software.com, a
developer of high-end Internet mail and messaging software systems. In
recent months, several Internet governance and independent groups have
been pushing for radical changes in the DNS. Web Week asked the man who
built it for his opinions of these proposed DNS changes.

WEB WEEK: It's been 10 years since the standards for the Internet's
domain name system, RFC 1034 and 1035, were published, which you
authored. That's close to a century in Internet years. How do you
account for its longevity as a standard, and do you think it's time for
major revisions?

MOCKAPETRIS: The secret of success in protocol design is when a very
small set of concepts can be combined in a very large number of ways to
create a large number of facilities. Ugly protocols do this with a lot
of special cases. The difference is more than elegance: Implementations
come earlier for the small set concepts situation. This minimalist style
is one of the key factors in the success of the DNS to date.

However, the demands of today are significantly different than those at
the time of RFC1034 et al. The good news is that new folks are working
in the IETF to add security, dynamic update, incremental zone transfer,
and some other features to the DNS. See new RFCs issued in April. So
major additions are underway.

Some of these are done exactly the way I would have done them and are
consistent with the "old testament" DNS; others are completely
different. I made my share of mistakes in the original design and had my
share of successes; these new proposals will undoubtedly have a similar
distribution of success and failure.

However, I bet at least a couple of these will significantly expand the
scope and power of the DNS.

WEB WEEK:In recent months there've been several new developments
relating to Internet Domain Name issues. The most visible one to end
users has been the controversy over expanding the number of top-level
names available and the number of entities authorized to register
second-level names under those new top-level domains, beyond the .com,
.net. and other standard names.

Overall, how do you see these changes-as healthy for the Internet, as
aberrations that need to be rectified, as expected outcomes of the
commercial direction the Internet has taken in the past two years, etc.?

MOCKAPETRIS: I try to stay neutral in these debates, but since all of
the proposals I have seen are of the form "I'm from X, and X should be
in charge," it is hard to avoid parallels with the robber baron days of
railroads, etc. It is a power struggle, not a technical debate. In this
adversarial situation, none of the advocates seem to spend any time
improving their ideas; they merely try to find support and leverage. I
hope we get through this period quickly.

A good question is how the public interest should be defined and applied
to these questions. The government? NSF seems to have thrown up its
hands, and the international aspects are also paramount. If I was forced
to support a position, I'd pick the EFF's [Electronic Frontier Foundation's].

WEB WEEK: There were two meetings on domain name issues during N+I [the
Network + Interop trade show]-one a panel on DNS which included the
IAHC, NSI, and eDNS, another just the eDNS. Did you participate in
either of these, and how would you describe the outcome, if any, of
these sessions? Do you expect to see even more independent entities
besides eDNS entering the fray?

MOCKAPETRIS: The usual suspects said the usual things. The only good
sign was that the press is really beginning to take an interest, and
some detailed analysis may follow.

WEB WEEK: In 1987, DNS standards required that a fully qualified host
and domain name not exceed 63 characters; more recent standards seem to
have expanded that to 255 characters. Other standards appear to
constrain domain and host names to allow only alphabetic and numeric
characters, plus hyphen and dot, and no other characters. Are these
actually technical constraints, or will we see a further loosening in
what can qualify as a domain name-Unicode characters, for example, or
double-byte Japanese characters, etc.?

MOCKAPETRIS: The DNS standards require the total name be less than 255
octets, and that the strings between dots be 63 or less. However, when
you use a domain name to represent a hostname, mail domain, mailbox, IP
address, etc., the domain name you use has to follow both the rules for
domain names-very loose-and the rules for whatever hostnames, mail
domains, mailboxes, or whatever is appropriate.

I have been a bit disappointed to see people favoring approaches that
are more restrictive-for example excluding "_" [underscore] in host
names, as opposed to expanding names to use Unicode or whatever. It
seems wrongheaded to me. [Dr. Mockapetris added the following in a
follow-up e-mail clarification:]

MOCKAPETRIS: Octets, bytes, and characters are the same thing when one
talks about ASCII domain names. (Remember to count the dots as well.)
So names can be up to 255 characters long. Unicode and other systems to
allow accents, kanji, and arbitrary foreign character sets typically use
more than one byte/octet per character, though details vary, and I'm far
from an expert on character sets.

WEB WEEK: In general, are there any technical reasons that limit the
number of top-level domain names that can exist? If yes, what is that
number and what would need to be changed to increase it?

MOCKAPETRIS: I get misquoted a lot on this. I believe that there are no
problems in expanding the TLD space that we couldn't solve in time. In
fact, there may be no problems at all. But we don't know for sure, so I
would favor adding a small number (say 20) to start, then maybe 100,
then 1,000, etc., if you want to get to a very large number. I'm just
being cautious in my old age.

WEB WEEK: Are there other technical constraints (part of the
requirements of BIND) that, say, preclude top-level names from being
numeric characters only, like .800 or .1997?

MOCKAPETRIS: No.

WEB WEEK: Being single characters, like .z?

MOCKAPETRIS: No.

WEB WEEK: Beginning with a number, like .5th Ave.?

MOCKAPETRIS: No.

WEB WEEK: Being lots of characters-like .supercalafragilisticexpealidocious?

MOCKAPETRIS: A bit. Although, like "_", people seem to want to restrict
things for questionable reasons. DNS transactions take place in packets
that are limited to 512 bytes-very long names take up more space, so you
have less left for other things. So it's really an efficiency and power
argument, not a showstopper.

WEB WEEK: There is a move underway to migrate DNS software to commercial
products and away from the freely available BIND that you helped define
in the RFCs. What happens when you have a mixed group of DNS server
software, some of it freely available, some of it commercial-is the IETF
standard strong enough to manage commercial "enhancements" like those
included in Oracle's domain-name server/database technology? Is a new
draft of the IETF standard perhaps required now?

MOCKAPETRIS: It all should play together, although "enhancements" often
create incompatibilities. I think the IETF needs strong leadership in
this area or there will be a problem soon. The databases and GUIs
probably won't play together as well.

WEB WEEK: What is the technical feasibility of the DNS system supporting
distributed repositories similar to the type required for the IAHC/CORE
system to allow for multiple, perhaps unlimited, independent domain-name
registries? From your experience, how long do you think it would take to
develop such a system and field-test it for commercial use?

MOCKAPETRIS: Depends on your objectives and policy constraints. For the
current TLDs, if we wanted to, say, distribute .com registration, we
could do it crudely in a week or two and have a production-quality
system in a month or two. Getting two registrars to agree on policy and
to cooperate is the hard problem.

WEB WEEK: Although the IAHC documents make passing reference to the
IETF's DNS standards, there was no IETF "standards-setting process"
underway during the development of the IAHC domain-name plan. Is there a
role for the IETF process in determining the technical feasibility of ,
or at least reviewing, some of the changes in DNS underway right now?

MOCKAPETRIS: I was IETF chair for a while, and felt very strongly that
the IETF should take over this issue, rather than leaving it to the ISOC
[Internet Society]. However, the ISOC leadership clearly felt
differently, and the IETF membership mostly isn't interested in policy
questions. So I guess I was out of step with the membership.

The IAHC says it followed an open process because it solicited comment.
I have a little trouble with this, since the closed IAHC meetings don't
seem "open" to me. Its like they were behind a one-way mirror. Of
course, that still puts the IAHC near the top regarding openness, which
is a comment on the overall process.

--------------------------------------------------------
Reprinted from Web Week, Volume 3, Issue 15, May 19, 1997.
Mecklermedia Corp. All rights reserved. [http://www.iworld.com]
Keywords: electronic_commerce Date: 19970519

----
adam@cs.caltech.edu

You are a Berkeley mail master, Adam. And you can quote me on that.
-- Joe Kiniry