diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3071.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3071.txt | 563 |
1 files changed, 0 insertions, 563 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3071.txt b/contrib/bind9/doc/rfc/rfc3071.txt deleted file mode 100644 index 2c4d52f..0000000 --- a/contrib/bind9/doc/rfc/rfc3071.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -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] - |
