30 years of RFC 1591: Time to reflect on the policy gaps for ccTLDs

Blog 19-03-2024

Since the times of Rod Beckstrom, ICANN has stayed far away from mainstream religion. There is, however, one document that acquired a quasi-religious status: RFC 1591

This month, this document turned 30 years old. Titled "Domain Name System Structure and Delegation”, it established the DNS as a global, distributed, and scalable system for managing domain names. By setting the foundational policies for top level domain name registration and delegation, it has significantly contributed to the stability and functionality of the internet. Most importantly for ccTLDs, it truly globalised the DNS by allowing policies for each ccTLD to be set locally and therefore be adapted to local needs and regulations. 

Yet, 30 years is a long time in the digital world. From thousands of domains in the early 90s, the DNS grew to more than 300 million second level domain names today. Some of the assumptions in the document have been proven inaccurate. Other parts have become obsolete. The personal connections at that time evaded the need for documented processes. Self-evident rules in 1994, read differently and are often confusing in today’s legal and geo-political setting. 

Additionally, there are now more documents than just RFC 1591 to govern the delegation, transfer, revocation, and retirement of a ccTLD. There is a framework of interpretation of RFC 1591, there is a policy developed by the ccNSO that handles retirement of ccTLDs, and other processes are being developed for the delegation of Internationalised Domain Names (IDNs).

The fact that parts of RFC 1591 have become obsolete, paired with the complex set of additional guidelines, have made this set of rules almost inaccessible for anyone who has not been following the debates in the last decades. It has also led to several policy gaps, with two examples illustrating them well.

First, while we are currently discussing data accuracy for registrants (e.g. in the context of the implementation of NIS 2), it is estimated that about 10% of the records and contact details for TLD managers are inaccurate. Even though there is an obligation for TLD managers to keep their data accurate, there is no enforcement mechanism to guarantee the accuracy of that data in the PTI database. Unreachability of the TLD manager could lead to security and stability issues.  

A second example is the lack of a predictable rule set in case a ccTLD manager wants to retire and nobody from their community wants to take over the management of that ccTLD. The .lb case illustrates the extreme complexities of this scenario.  

In an outstanding session at the ccNSO in San Juan, the community started to ask the right questions. Should there be a consolidated document that encompasses all these policies? If so, how are policy gaps addressed? By new policy or interpretation? How do we avoid that this exercise dies in the drifting sands of detail? What is the current approach to scenarios that are undocumented? How do we avoid the fiction that all incidents can be predicted and addressed in a policy? How do we match the need for predictability with the agility the next 30 years will require?

This will be a fascinating but long and sensitive discussion. The path will be winding. The obstacles will be daunting. But at a time when more and more interested parties are asking rightful questions, it is unavoidable to address these issues and keep the legacy of RFC 1591 and its author intact. 

A key paragraph could be dusted off and get the spotlight it deserves: “Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community. - RFC 1591 Jon Postel, March 1994”. 

Published By Peter Van Roste
Peter Van Roste is the General Manager of CENTR, overseeing all of CENTR’s activities and liaising with governments, institutions and other organisations in the internet ecosystem.

Related News

Blog 18-03-2024
ICANN79: Milestones achieved and expectations raised

ICANN79: Milestones achieved and expecta...

Polina Malaja