564 lines
24 KiB
Plaintext
564 lines
24 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group J. Klensin
|
||
Request for Comments: 3071 February 2001
|
||
Category: Informational
|
||
|
||
|
||
Reflections on the DNS, RFC 1591, and Categories of Domains
|
||
|
||
Status of this Memo
|
||
|
||
This memo provides information for the Internet community. It does
|
||
not specify an Internet standard of any kind. Distribution of this
|
||
memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
RFC 1591, "Domain Name System Structure and Delegation", laid out the
|
||
basic administrative design and principles for the allocation and
|
||
administration of domains, from the top level down. It was written
|
||
before the introduction of the world wide web (WWW) and rapid growth
|
||
of the Internet put significant market, social, and political
|
||
pressure on domain name allocations. In recent years, 1591 has been
|
||
cited by all sides in various debates, and attempts have been made by
|
||
various bodies to update it or adjust its provisions, sometimes under
|
||
pressures that have arguably produced policies that are less well
|
||
thought out than the original. Some of those efforts have begun from
|
||
misconceptions about the provisions of 1591 or the motivation for
|
||
those provisions. The current directions of the Internet Corporation
|
||
for Assigned Names and Numbers (ICANN) and other groups who now
|
||
determine the Domain Name System (DNS) policy directions appear to be
|
||
drifting away from the policies and philosophy of 1591. This
|
||
document is being published primarily for historical context and
|
||
comparative purposes, essentially to document some thoughts about how
|
||
1591 might have been interpreted and adjusted by the Internet
|
||
Assigned Numbers Authority (IANA) and ICANN to better reflect today's
|
||
world while retaining characteristics and policies that have proven
|
||
to be effective in supporting Internet growth and stability. An
|
||
earlier variation of this memo was submitted to ICANN as a comment on
|
||
its evolving Top-level Domain (TLD) policies.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 1]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
1. Introduction
|
||
|
||
RFC 1591 [1] has been heavily discussed and referenced in the last
|
||
year or two, especially in discussions within ICANN and its
|
||
predecessors about the creation, delegation, and management of top-
|
||
level domains. In particular, the ICANN Domain Name Supporting
|
||
Organization (DNSO), and especially its ccTLD constituency, have been
|
||
the home of many discussions in which 1591 and interpretations of it
|
||
have been cited in support of a variety of sometimes-contradictory
|
||
positions. During that period, other discussions have gone on to try
|
||
to reconstruct the thinking that went into RFC 1591. Those in turn
|
||
have led me and others to muse on how that original thinking might
|
||
relate to some of the issues being raised. 1591 is, I believe, one
|
||
of Jon Postel's masterpieces, drawing together very different
|
||
philosophies (e.g., his traditional view that people are basically
|
||
reasonable and will do the right thing if told what it is with some
|
||
stronger mechanisms when that model is not successful) into a single
|
||
whole.
|
||
|
||
RFC 1591 was written in the context of the assumption that what it
|
||
described as generic TLDs would be bound to policies and categories
|
||
of registration (see the "This domain is intended..." text in
|
||
section 2) while ccTLDs were expected to be used primarily to support
|
||
users and uses within and for a country and its residents. The
|
||
notion that different domains would be run in different ways --albeit
|
||
within the broad contexts of "public service on behalf of the
|
||
Internet community" and "trustee... for the global Internet
|
||
community"-- was considered a design feature and a safeguard against
|
||
a variety of potential abuses. Obviously the world has changed in
|
||
many ways in the seven or eight years since 1591 was written. In
|
||
particular, the Internet has become more heavily used and, because
|
||
the design of the world wide web has put domain names in front of
|
||
users, top-level domain names and registrations in them have been
|
||
heavily in demand: not only has the number of hosts increased
|
||
dramatically during that time, but the ratio between registered
|
||
domain names and physical hosts has increased very significantly.
|
||
|
||
The issues 1591 attempted to address when it was written and those we
|
||
face today have not changed significantly in principle. But one
|
||
alternative to present trends would be to take a step back to refine
|
||
it into a model that can function effectively today. Therefore, it
|
||
may be useful to try to reconstruct 1591's principles and think about
|
||
their applicability today as a model that could continue to be
|
||
applied: not because it is historically significant, but because many
|
||
of its elements have proven to work reasonably well, even in
|
||
difficult situations. In particular, for many domains (some in
|
||
1591's "generic" list and others in its "country code" category) the
|
||
notion of "public service" --expected then to imply being carried out
|
||
|
||
|
||
|
||
Klensin Informational [Page 2]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
at no or minimal cost to the users, not merely on a non-profit
|
||
basis-- has yielded to profitability calculations. And, in most of
|
||
the rest, considerations of at least calculating and recovering costs
|
||
have crept in. While many of us feel some nostalgia for the old
|
||
system, it is clear that its days are waning if not gone: perhaps the
|
||
public service notions as understood when 1591 was written just don't
|
||
scale to rapid internet growth and very large numbers of
|
||
yregistrations.
|
||
|
||
In particular, some ccTLDs have advertised for registrations outside
|
||
the designated countries (or other entities), while others have made
|
||
clear decisions to allow registrations by non-nationals. These
|
||
decisions and others have produced protests from many sides,
|
||
suggesting, in turn, that a recategorization is in order. For
|
||
example, we have heard concerns by governments and managers of
|
||
traditional, "public service", in-country, ccTLDs about excessive
|
||
ICANN interference and fears of being forced to conform to
|
||
internationally-set policies for dispute resolution when their
|
||
domestic ones are considered more appropriate. We have also heard
|
||
concerns from registrars and operators of externally-marketed ccTLDs
|
||
about unreasonable government interference and from gTLD registrars
|
||
and registries about unreasonable competition from aggressively
|
||
marketed ccTLDs. The appropriate distinction is no longer between
|
||
what RFC 1591 described as "generic" TLDs (but which were really
|
||
intended to be "purpose-specific", a term I will use again below) and
|
||
ccTLDs but among:
|
||
|
||
(i) true "generic" TLDs, in which any registration is acceptable
|
||
and, ordinarily, registrations from all sources are actively
|
||
promoted. This list currently includes (the formerly purpose-
|
||
specific) COM, NET, and ORG, and some ccTLDs. There have been
|
||
proposals from time to time for additional TLDs of this variety in
|
||
which, as with COM (and, more recently, NET and ORG) anyone
|
||
(generally subject only to name conflicts and national law) could
|
||
register who could pay the fees.
|
||
|
||
(ii) purpose-specific TLDs, in which registration is accepted only
|
||
from organizations or individuals meeting particular
|
||
qualifications, but where those qualifications are not tied to
|
||
national boundaries. This list currently includes INT, EDU, the
|
||
infrastructure domain ARPA, and, arguably, the specialized US
|
||
Government TLDs MIL and GOV. There have been proposals from time
|
||
to time for other international TLDs of this variety, e.g., for
|
||
medical entities such as physicians and hospitals and for museums.
|
||
ICANN has recently approved several TLDs of this type and
|
||
describes them as "sponsored" TLDs.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 3]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
(iii) Country domains, operated according to the original
|
||
underlying assumptions of 1591, i.e., registrants are largely
|
||
expected to be people or other entities within the country. While
|
||
external registrations might be accepted by some of these, the
|
||
country does not aggressively advertise for such registrations,
|
||
nor does anyone expect to derive significant fee revenue from
|
||
them. All current domains in this category are ccTLDs, but not
|
||
all ccTLDs are in this category.
|
||
|
||
These categories are clearly orthogonal to the association between
|
||
the use of the IS 3166-1 registered code list [2] and two-letter
|
||
"country" domain names. If that relationship is to be maintained
|
||
(and I believe it is desirable), the only inherent requirement is
|
||
that no two-letter TLDs be created except from that list (in order to
|
||
avoid future conflicts). ICANN should control the allocation and
|
||
delegation of TLDs using these, and other, criteria, but only
|
||
registered 3166-1 two letter codes should be used as two-letter TLDs.
|
||
|
||
2. Implications of the Categories
|
||
|
||
If we had adopted this type of three-way categorization and could
|
||
make it work, I believe it would have presented several opportunities
|
||
for ICANN and the community more generally to reduce controversies
|
||
and move forward. Of course, there will be cases where the
|
||
categorization of a particular domain and its operating style will
|
||
not be completely clear-cut (see section 3, below). But having ICANN
|
||
work out procedures for dealing with those (probably few) situations
|
||
appears preferable to strategies that would tend to propel ICANN into
|
||
areas that are beyond its competence or that might require
|
||
significant expansion of its mandate.
|
||
|
||
First, the internally-operated ccTLDs (category iii above) should not
|
||
be required to have much interaction with ICANN or vice versa. Once
|
||
a domain of this sort is established and delegated, and assuming that
|
||
the "admin contact in the country" rule is strictly observed, the
|
||
domain should be able to function effectively without ICANN
|
||
intervention or oversight. In particular, while a country might
|
||
choose to adopt the general ICANN policies about dispute resolution
|
||
or name management, issues that arise in these areas might equally
|
||
well be dealt with exclusively under applicable national laws. If a
|
||
domain chooses to use ICANN services that cost resources to provide,
|
||
it should contribute to ICANN's support, but, if it does not, ICANN
|
||
should not presume to charge it for other than a reasonable fraction
|
||
of the costs to ICANN of operating the root, root servers, and any
|
||
directory systems that are generally agreed upon to be necessary and
|
||
in which the domain participates.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 4]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
By contrast, ccTLDs operated as generic domains ought to be treated
|
||
as generic domains. ICANN dispute resolution and name management
|
||
policies and any special rules developed to protect the Internet
|
||
public in multiple registrar or registry situations should reasonably
|
||
apply.
|
||
|
||
3. Telling TLD types apart
|
||
|
||
If appropriate policies are adopted, ccTLDs operated as generic
|
||
domains (category (i) above) and those operated as country domains
|
||
(category (iii) above) ought to be able to be self-identified. There
|
||
are several criteria that could be applied to make this
|
||
determination. For example, either a domain is aggressively seeking
|
||
outside registrations or it is not and either the vast majority of
|
||
registrants in a domain are in-country or they are not. One could
|
||
also think of this as the issue of having some tangible level of
|
||
presence in the jurisdiction - e.g., is the administrative contact
|
||
subject, in practical terms, to the in-country laws, or are the
|
||
registration rules such that it is reasonably likely that a court in
|
||
the jurisdiction of the country associated with the domain can
|
||
exercise jurisdiction and enforce a judgment against the registrant.
|
||
|
||
One (fairly non-intrusive) rule ICANN might well impose on all top-
|
||
level domains is that they identify and publish the policies they
|
||
intend to use. E.g., registrants in a domain that will use the laws
|
||
of one particular country to resolve disputes should have a
|
||
reasonable opportunity to understand those policies prior to
|
||
registration and to make other arrangements (e.g., to register
|
||
elsewhere) if that mechanism for dispute resolution is not
|
||
acceptable. Giving IANA (as the root registrar) incorrect
|
||
information about the purpose and use of a domain should be subject
|
||
to challenge, and should be grounds for reviewing the appropriateness
|
||
of the domain delegation, just as not acting consistently and
|
||
equitably provides such grounds under the original provisions of RFC
|
||
1591.
|
||
|
||
In order to ensure the availability of accurate and up-to-date
|
||
registration information the criteria must be consistent, and
|
||
consistent with more traditional gTLDs, for all nominally country
|
||
code domains operating as generic TLDs.
|
||
|
||
4. The role of ICANN in country domains
|
||
|
||
ICANN (and IANA) should, as described above, have as little
|
||
involvement as possible in the direction of true country [code]
|
||
domains (i.e., category (iii)). There is no particular reason why
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 5]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
these domains should be subject to ICANN regulation beyond the basic
|
||
principles of 1591 and associated arrangements needed to ensure
|
||
Internet interoperability and stability.
|
||
|
||
ICANN's avoiding such involvement strengthens it: the desirability of
|
||
avoiding collisions with national sovereignty, determinations about
|
||
government legitimacy, and the authority of someone purportedly
|
||
writing on behalf of a government, is as important today as it was
|
||
when 1591 was written. The alternatives take us quickly from
|
||
"administration" into "internet governance" or, in the case of
|
||
determining which claimant is the legitimate government of a country,
|
||
"international relations", and the reasons for not moving in that
|
||
particular direction are legion.
|
||
|
||
5. The role of governments
|
||
|
||
The history of IANA strategy in handling ccTLDs included three major
|
||
"things to avoid" considerations:
|
||
|
||
* Never get involved in determining which entities were countries
|
||
and which ones were not.
|
||
|
||
* Never get involved in determining who was, or was not, the
|
||
legitimate government of a country. And, more generally, avoid
|
||
deciding what entity --government, religion, commercial,
|
||
academic, etc.-- has what legitimacy or rights.
|
||
|
||
* If possible, never become involved in in-country disputes.
|
||
Instead, very strongly encourage internal parties to work
|
||
problems out among themselves. At most, adopt a role as
|
||
mediator and educator, rather than judge, unless abuses are very
|
||
clear and clearly will not be settled by any internal mechanism.
|
||
|
||
All three considerations were obviously intended to avoid IANA's
|
||
being dragged into a political morass in which it had (and, I
|
||
suggest, has) no competence to resolve the issues and could only get
|
||
bogged down. The first consideration was the most visible (and the
|
||
easiest) and was implemented by strict and careful adherence (see
|
||
below) to the ISO 3166 registered Country Code list. If an entity
|
||
had a code, it was eligible to be registered with a TLD (although
|
||
IANA was free to apply additional criteria-most of them stated in
|
||
1591). If it did not, there were no exceptions: the applicant's only
|
||
recourse was a discussion with the 3166 Registration Authority (now
|
||
Maintenance Agency, often known just as "3166/MA") or the UN
|
||
Statistical Office (now Statistics Bureau), not with IANA.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 6]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
There are actually five ccTLD exceptions to the strict rules. One,
|
||
"UK", is historical: it predates the adoption of ISO 3166 for this
|
||
purpose. The others --Ascension Island, Guernsey, Isle of Man, and
|
||
Jersey --are arguably, at least in retrospect, just mistakes.
|
||
Regardless of the historical reasons (about which there has been much
|
||
speculation), it is almost certainly the case that the right way to
|
||
handle mistakes of this sort is to acknowledge them and move on,
|
||
rather than trying to use them as precedents to justify more
|
||
mistakes.
|
||
|
||
This, obviously, is also the argument against use of the "reserved"
|
||
list (technically internal to the 3166 maintenance activity, and not
|
||
part of the Standard): since IANA (or ICANN) can ask that a name be
|
||
placed on that list, there is no rule of an absolute determination by
|
||
an external organization. Purported countries can come to ICANN,
|
||
insist on having delegations made and persuade ICANN to ask that the
|
||
names be reserved. Then, since the reserved name would exist, they
|
||
could insist that the domain be delegated. Worse, someone could use
|
||
another organization to request reservation of the name by 3166/MA;
|
||
once it was reserved, ICANN might be hard-pressed not to do the
|
||
delegation. Of course, ICANN could (and probably would be forced to)
|
||
adopt additional criteria other than appearance on the "reserved
|
||
list" in order to delegate such domains. But those criteria would
|
||
almost certainly be nearly equivalent to determining which applicants
|
||
were legitimate and stable enough to be considered a country, the
|
||
exact decision process that 1591 strove to avoid.
|
||
|
||
The other two considerations were more subtle and not always
|
||
successful: from time to time, both before and after the formal
|
||
policy shifted toward "governments could have their way", IANA
|
||
received letters from people purporting to be competent government
|
||
authorities asking for changes. Some of them turned out later to not
|
||
have that authority or appropriate qualifications. The assumption of
|
||
1591 itself was that, if the "administrative contact in country" rule
|
||
was strictly observed, as was the rule that delegation changes
|
||
requested by the administrative contact would be honored, then, if a
|
||
government _really_ wanted to assert itself, it could pressure the
|
||
administrative contact into requesting the changes it wanted, using
|
||
whatever would pass for due process in that country. And the ability
|
||
to apply that process and pressure would effectively determine who
|
||
was the government and who wasn't, and would do so far more
|
||
effectively than any IANA evaluation of, e.g., whether the letterhead
|
||
on a request looked authentic (and far more safely for ICANN than
|
||
asking the opinion of any particular other government or selection of
|
||
governments).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 7]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
Specific language in 1591 permitted IANA to adopt a "work it out
|
||
yourselves; if we have to decide, we will strive for a solution that
|
||
is not satisfactory to any party" stance. That approach was used
|
||
successfully, along with large doses of education, on many occasions
|
||
over the years, to avoid IANA's having to assume the role of judge
|
||
between conflicting parties.
|
||
|
||
Similar principles could be applied to the boundary between country-
|
||
code-based generic TLDs and country domains. Different countries,
|
||
under different circumstances, might prefer to operate the ccTLD
|
||
either as a national service or as a profit center where the
|
||
"customers" were largely external. Whatever decisions were made
|
||
historically, general Internet stability argues that changes should
|
||
not be made lightly. At the same time, if a government wishes to
|
||
make a change, the best mechanism for doing so is not to involve
|
||
ICANN in a potential determination of legitimacy (or even to have
|
||
ICANN's Government Advisory Committee (GAC) try to formally make that
|
||
decision for individual countries) but for the relevant government to
|
||
use its own procedures to persuade the administrative contact to
|
||
request the change and for IANA to promptly and efficiently carry out
|
||
requests made by administrative contacts.
|
||
|
||
6. Implications for the current ICANN DNSO structure.
|
||
|
||
The arguments by some of the ccTLD administrators that they are
|
||
different from the rest of the ICANN and DNSO structures are (in this
|
||
model) correct: they are different. The ccTLDs that are operating as
|
||
generic TLDs should be separated from the ccTLD constituency and
|
||
joined to the gTLD constituency. The country ccTLDs should be
|
||
separated from ICANN's immediate Supporting Organization structure,
|
||
and operate in a parallel and advisory capacity to ICANN, similar to
|
||
the arrangements used with the GAC. The DNSO and country TLDs should
|
||
not be required to interact with each other except on a mutually
|
||
voluntary basis and, if ICANN needs interaction or advice from some
|
||
of all of those TLDs, it would be more appropriate to get it in the
|
||
form of an advisory body like the GAC rather than as DNSO
|
||
constituency.
|
||
|
||
7. References
|
||
|
||
[1] Postel, J., "Domain Name System Structure and Delegation", RFC
|
||
1591, March 1994.
|
||
|
||
[2] ISO 3166. ISO 3166-1. Codes for the representation of names of
|
||
countries and their subdivisions - Part 1: Country codes (1997).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 8]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
8. Acknowledgements and disclaimer
|
||
|
||
These reflections have been prepared in my individual capacity and do
|
||
not necessarily reflect the views of my past or present employers.
|
||
Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
|
||
Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
|
||
suggestions or offered editorial comments about earlier versions of
|
||
this document. Cord Wischhoefer, of the ISO 3166/MA, was also kind
|
||
enough to look at the draft and supplied some useful details. Those
|
||
comments contributed significantly to whatever clarity the document
|
||
has, but the author bears responsibility for the selection of
|
||
comments which were ultimately incorporated and the way in which the
|
||
conclusions were presented.
|
||
|
||
9. Security Considerations
|
||
|
||
This memo addresses the context for a set of administrative decisions
|
||
and procedures, and does not raise or address security issues.
|
||
|
||
10. Author's Address
|
||
|
||
John C. Klensin
|
||
1770 Massachusetts Ave, Suite 322
|
||
Cambridge, MA 02140, USA
|
||
|
||
EMail: klensin@jck.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 9]
|
||
|
||
RFC 3071 Reflections on the DNS and RFC 1591 February 2001
|
||
|
||
|
||
11. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society 2001. All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others provided that the above copyright notice and this paragraph
|
||
are included on all such copies. However, this document itself may
|
||
not be modified in any way, such as by removing the copyright notice
|
||
or references to the Internet Society or other Internet
|
||
organizations, except as required to translate it into languages
|
||
other than English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Informational [Page 10]
|
||
|