RFC 3071

Reflections on the DNS, RFC 1591, and Categories of Domains

📅 published February 2001, from ietf

Reflections on the DNS, RFC 1591, and Categories of Domains 🌸

Network Working Group · Request for Comments: 3071 · Author: J. Klensin · February 2001 · Category: Informational 🦋

Quick header tea: this doc is from February 2001, it's Informational (so it's just sharing thoughts, not a standard 💅), and the header doesn't list anything it obsoletes or updates. Okay, let's dive in! 🧚

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🦋

Okay so, RFC 1591, "Domain Name System Structure and Delegation," set up the basic admin design and principles for handing out and running domains, from the top levels down. It was written before the world wide web (WWW) and the rapid growth of the Internet put huge market, social, and political pressure on domain name allocations. 😭

Lately 1591 has been cited by everyone in various debates, and different groups have tried to update it or tweak its rules. Some of those efforts were kind of messy, with policies arguably less well thought out than the original, and some started from misconceptions about what 1591 actually says or why. 🙈 The current directions of the Internet Corporation for Assigned Names and Numbers (ICANN) and other groups that now shape the Domain Name System (DNS) policy seem to be drifting away from 1591's policies and philosophy. 💀

So this doc is mainly for historical context and comparison. It's basically documenting some thoughts on how 1591 could have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to fit today's world, while keeping the stuff that has really worked for Internet growth and stability. 🌈 An earlier version was submitted to ICANN as a comment on its evolving Top-level Domain (TLD) policies.

1. Introduction ✨

RFC 1591 [1] has been seriously everywhere over the last year or two, especially in ICANN discussions and its predecessors about creating, delegating, and managing top-level domains. The ICANN Domain Name Supporting Organization (DNSO), and especially its ccTLD constituency, has been the home of tons of these discussions, where 1591 got cited to back up a bunch of sometimes-contradictory positions. 🙃 Other folks went on to try to reconstruct the thinking behind RFC 1591, and that made me (and others) muse about how that original thinking relates to today's issues. 🧠

Honestly, 1591 is one of Jon Postel's masterpieces 👑. It pulled together very different philosophies into one whole. For example, he had this traditional view that people are basically reasonable and will do the right thing if you tell them what it is, with some stronger mechanisms for when that model doesn't work. It's giving wise and iconic at the same time. 🫶

RFC 1591 was written assuming that what it called generic TLDs would be bound to policies and categories of registration (check the "This domain is intended..." text in section 2 for the vibe 🎀), while ccTLDs were expected to mainly support users and uses within and for a country and its residents. The idea that different domains would run in different ways (all within the broad contexts of "public service on behalf of the Internet community" and "trustee... for the global Internet community") was seen as a design feature and a safeguard against all kinds of potential abuses. 🛡️ Obviously the world has changed a lot in the seven or eight years since 1591 was written. The Internet is way more heavily used, and because the WWW put domain names right in front of users, top-level domain names and registrations in them have been in massive demand. 📈 The number of hosts went up dramatically, and the ratio between registered domain names and physical hosts increased really significantly. 💅

The issues 1591 tried to address back then, and the ones we're facing now, haven't really changed much in principle. 🦋 One alternative to the current trends would be to step back and refine 1591 into a model that can work well today. So it might be useful to reconstruct 1591's principles and think about how they apply now, as a model that could keep being applied. Not because it's historically significant, but because lots of its elements have proven to work reasonably well, even in difficult situations. ✨

Here's the tea ☕: for many domains (some on 1591's "generic" list and others in its "country code" category), the notion of "public service" has yielded to profitability calculations. "Public service" was expected to mean being run at no or minimal cost to users, not just on a non-profit basis. 😔 In most of the rest, calculating and recovering costs has crept in. A lot of us feel nostalgic for the old system, but it's clear its days are waning, if not gone. Maybe the public service notions as understood when 1591 was written just don't scale to rapid Internet growth and very large numbers of registrations. 🥺

Some ccTLDs have advertised for registrations outside their designated countries (or other entities), and others have clearly decided to allow registrations by non-nationals. 🌍 These decisions and others have caused protests from many sides, which suggests a recategorization is in order. For instance, governments and managers of traditional "public service," in-country ccTLDs have voiced concerns about excessive ICANN interference, and about being forced to conform to internationally-set policies for dispute resolution when their domestic ones are considered more appropriate. 🙅‍♀️ Registrars and operators of externally-marketed ccTLDs have raised concerns about unreasonable government interference. And gTLD registrars and registries have complained about unreasonable competition from aggressively marketed ccTLDs. 😤

So the appropriate distinction is no longer between what RFC 1591 described as "generic" TLDs (which were really intended to be "purpose-specific," a term I'll use again below) and ccTLDs. It's now among these three buckets: 🎀

  • (i) True "generic" TLDs, where 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, plus some ccTLDs. There have been proposals from time to time for more TLDs like this, where anyone (generally subject only to name conflicts and national law) could register as long as they could pay the fees. 💖
  • (ii) Purpose-specific TLDs, where registration is accepted only from organizations or individuals meeting particular qualifications, but those qualifications aren't 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 kind, for example for medical entities like physicians and hospitals, and for museums. 🏥🏛️ ICANN has recently approved several TLDs of this type and describes them as "sponsored" TLDs. 🌟
  • (iii) Country domains, operated according to the original underlying assumptions of 1591. That means registrants are largely expected to be people or other entities within the country. While some of these might accept external registrations, the country doesn't aggressively advertise for them, and nobody expects to earn 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 going to be maintained (and I believe it's desirable), the only inherent requirement is that no two-letter TLDs get created except from that list, to avoid future conflicts. ICANN should control the allocation and delegation of TLDs using these criteria and other ones, 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 three-way categorization and could actually make it work, I honestly believe it would have given ICANN and the wider community several chances to reduce controversies and move forward. 🌷 Of course, there will be cases where a particular domain's categorization and operating style aren't totally clear-cut (see section 3, below). But having ICANN work out procedures for those (probably few) situations seems way better than strategies that would push ICANN into areas beyond its competence, or that would need a major expansion of its mandate. 🚫

First, the internally-operated ccTLDs (category iii above) shouldn't be required to have much interaction with ICANN, or vice versa. 🙅‍♀️ Once a domain like this is established and delegated, and assuming the "admin contact in the country" rule is strictly observed, the domain should be able to function effectively without ICANN intervention or oversight. ✨ A country might choose to adopt the general ICANN policies about dispute resolution or name management, but issues in those areas might just as well be dealt with exclusively under applicable national laws. 🏳️ And if a domain chooses to use ICANN services that cost resources to provide, it should contribute to ICANN's support. But if it doesn't, ICANN shouldn't presume to charge it for anything 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. 💸

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. 👑 Part 2 is coming up next, so stay tuned, bestie 🦋💜

3. Telling TLD types apart 🎀

okay so bestie, this section is about how we could tell apart the ccTLDs that are secretly acting like generic domains (category (i)) from the ones that are real country domains (category (iii)) 👀✨. and honestly? it's giving "the labels should be honest" energy 💅

there are a few criteria that could be used to figure this out. for example, is a domain aggressively going after outside registrations, or nah? and is the vast majority of its registrants in-country, or not? 🌸 another way to think about it is tangible presence in the jurisdiction. like, is the administrative contact actually subject to the in-country laws in practical terms? or are the registration rules set up so a court in that country could realistically exercise jurisdiction and enforce a judgment against the registrant? 🧚 that's the main character question of this whole section ngl

now, one (fairly non-intrusive) rule ICANN might totally impose on all top-level domains is that they identify and publish the policies they intend to use 📖💜 this is lowkey the most chill ask ever. like, registrants in a domain that uses one country's laws to settle disputes should get a fair chance to understand those policies before they register, so they can go elsewhere if that dispute process isn't okay with them 🙈

and if someone gives IANA (as the root registrar) incorrect info about what a domain is for and how it's used, that should be open to challenge 🚩. it should be grounds for reviewing whether the domain delegation is still appropriate, same way that not acting consistently and equitably already gives grounds under the original provisions of RFC 1591 💅

finally, to keep registration info accurate and up-to-date, the criteria have to 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 🌍

okay so ICANN (and IANA) should, like we said above, have as little involvement as possible in the direction of true country [code] domains (that's category (iii)) 🫶 there's no real reason these domains need ICANN regulation beyond the basic principles of 1591 and the arrangements needed for Internet interoperability and stability 🔥

and ngl, ICANN avoiding that involvement actually makes it stronger 👑 the stuff that matters here, like avoiding collisions with national sovereignty, not deciding government legitimacy, and not overstepping who's really writing on behalf of a government, is just as important today as when 1591 was written 😭 the alternatives take us straight from "administration" into "internet governance" or, when you're figuring out which claimant is the legit government of a country, into "international relations" 💀 and the reasons for not going that way are legion 🙈

5. The role of governments 🏛️

so the history of IANA strategy for ccTLDs had three major "things to avoid" 🚫

* 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 were obviously meant to keep IANA out of a political morass where it had (and, I suggest, has) no competence to resolve things and could only get bogged down 😩 the first one was the most visible (and the easiest) and got 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 didn't, 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 🧚

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 (which people have speculated about a LOT), it's almost certainly right to acknowledge mistakes like these and move on, rather than using them as precedents to justify more mistakes 🫠🌈

this is also the argument against using the "reserved" list 📛 (technically internal to the 3166 maintenance activity, and not part of the Standard). since IANA (or ICANN) can ask for a name to be placed on that list, there's no rule of absolute determination by an external organization 😵 purported countries could come to ICANN, insist on delegations, and persuade ICANN to ask that the names be reserved. then, since the reserved name would exist, they could insist the domain be delegated 🙃 worse, someone could use another organization to request reservation of the name by 3166/MA, and once it was reserved, ICANN might be hard-pressed not to do the delegation 😭 sure, ICANN could (and probably would be forced to) adopt extra criteria beyond appearing on the "reserved list" to delegate such domains. but those criteria would almost certainly be nearly equivalent to deciding which applicants were legitimate and stable enough to be considered a country, which is exactly the decision process 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 got letters from people claiming to be competent government authorities asking for changes 📨 some of them turned out later not to have that authority or the right qualifications 🙈 the assumption behind 1591 was that if the "administrative contact in country" rule was strictly observed, and the rule that delegation changes requested by the administrative contact would be honored, then a government that really wanted to assert itself could pressure the administrative contact into requesting the changes it wanted, using whatever would pass for due process in that country 🫣 the ability to apply that process and pressure would effectively decide who the government was, and it would do that 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) 🧠✨

1591 specifically let IANA take 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, so IANA didn't have to become the judge between conflicting parties 👑

similar principles could apply to the boundary between country-code-based generic TLDs and country domains 🌸 different countries, in different circumstances, might prefer to run the ccTLD either as a national service or as a profit center where the "customers" were mostly external 💰 whatever was decided historically, general Internet stability argues that changes shouldn't be made lightly ⚖️ at the same time, if a government wants to make a change, the best way to do it isn't 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). instead, the relevant government should use its own procedures to persuade the administrative contact to request the change, and IANA should promptly and efficiently carry out requests made by administrative contacts 🎀💖

6. Implications for the current ICANN DNSO structure 🧩

the arguments from some ccTLD administrators that they're different from the rest of the ICANN and DNSO structures are (in this model) correct: they are different 🙌 the ccTLDs 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 or all of those TLDs, it would be more appropriate to get it through an advisory body like the GAC, rather than as a 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).

8. Acknowledgements and disclaimer 💜

these reflections were prepared in my individual capacity and don't 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 on 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 that were ultimately incorporated and for the way 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

okay bestie, this is the legal bit, but it's actually simple 💅 Here's the official copyright line, copied exactly:

Copyright (C) The Internet Society 2001. All Rights Reserved.

So the vibe is: you can copy this doc and share it with people, as long as the copyright notice and this paragraph are on every copy 📄 But you can't modify the document itself. That means no deleting the copyright notice or the references to the Internet Society or other Internet organizations. The only exception is translating it into languages other than English 🌍

The permissions here are perpetual, which means they won't be revoked by the Internet Society or its successors or assigns ✨

The disclaimer is the all-caps part, and it's giving serious legal energy 😭 Here it is exactly as written:

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.

In normal words: the doc is handed over "as is," and the Internet Society and the Internet Engineering Task Force say no warranties, express or implied, including that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 🙈

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💜 So the people keeping the RFC series running are backed by the ISOC right now, which is lowkey iconic 👑

📦 where this page comes from