Login
In 1987, CompuServe introduced GIF images, Steve Wozniak left Apple and IBM introduced the PS/2 personal computer with improved graphics and a 3.5-inch diskette drive. Behind the scenes, one more critical piece of internet infrastructure was quietly taking form to help establish the internet we know today.
November of 1987 saw the establishment of the Domain Name System protocol suite as internet standards. This was a development that not only would begin to open the internet to individuals and businesses globally, but also would arguably redefine communications, commerce and access to information for future generations.
Today, the DNS continues to be critical to the operation of the internet as a whole. It has a long and strong track record thanks to the work of the internet’s pioneers and the collaboration of different groups to create volunteer standards.
Let’s take a look back at the journey of the DNS over the years.
Prior to 1987, the internet was primarily used by government agencies and members of academia. Back then, the Network Information Center, managed by SRI International, manually maintained a directory of hosts and networks. While the early internet was transformative and forward-thinking, not everyone had access to it.
During that same time period, the U.S. Advanced Research Projects Agency Network, the forerunner to the internet we know now, was evolving into a growing network environment, and new naming and addressing schemes were being proposed. Seeing that there were thousands of interested institutions and companies wanting to explore the possibilities of networked computing, a group of ARPA networking researchers realized that a more modern, automated approach was needed to organize the network’s naming system for anticipated rapid growth.
Two Request for Comments documents, numbered RFC 1034 and RFC 1035, were published in 1987 by the informal Network Working Group, which soon after evolved into the Internet Engineering Task Force. Those RFCs, authored by computer scientist Paul V. Mockapetris, became the standards upon which DNS implementations have been built. It was Mockapetris, inducted into the Internet Hall of Fame in 2012, who specifically suggested a name space where database administration was distributed but could also evolve as needed.
In addition to allowing organizations to maintain their own databases, the DNS simplified the process of connecting a name that users could remember with a unique set of numbers – the Internet Protocol address – that web browsers needed to navigate to a website using a domain name. By not having to remember a seemingly random string of numbers, users could easily get to their intended destination, and more people could access the web. This has worked in a logical way for all internet users – from businesses large and small to everyday people – all around the globe.
With these two aspects of the DNS working together – wide distribution and name-to-address mapping – the DNS quickly took shape and developed into the system we know today.
Thirty-five years of DNS development and progress is attributable to the collaboration of multiple stakeholders and interest groups – academia, technical community, governments, law enforcement and civil society, plus commercial and intellectual property interests – who continue even today to bring crucial perspectives to the table as it relates to the evolution of the DNS and the internet. These perspectives have lent themselves to critical security developments in the DNS, from assuring protection of intellectual property rights to the more recent stakeholder collaborative efforts to address DNS abuse.
Other major collaborative achievements involve the IETF, which has no formal membership roster or requirements, and is responsible for the technical standards that comprise the internet protocol suite, and the Internet Corporation for Assigned Names and Numbers, which plays a central coordination role in the bottom-up multistakeholder system governing the global DNS. Without constructive and productive voluntary collaboration, the internet as we know it simply isn’t possible.
Indeed, these cooperative efforts marshaled a brand of collaboration known today as “rough consensus.” That term, originally “rough consensus and running code,” gave rise to a more dynamic collaboration process than the “100% consensus from everyone” model. In fact, the term was adopted by the IETF in the early days of establishing the DNS to describe the formation of the dominant view of the working group and the need to quickly implement new technologies, which doesn’t always allow for lengthy discussions and debates. This approach is still in use today, proving its usefulness and longevity.
As we look back on how the DNS came to be and the processes that have kept it reliably running, it’s important to recognize the work done by the organizations and individuals that make up this community. We must also remember that the efforts continue to be powered by voluntary collaborations.
Commemorating anniversaries such as 35 years of the DNS protocol allows the multiple stakeholders and communities to pause and reflect on the enormity of the work and responsibility before us. Thanks to the pioneering minds who conceived and built the early infrastructure of the internet, and in particular to Paul Mockapetris’s fundamental contribution of the DNS protocol suite, the world has been able to establish a robust global economy that few could ever have imagined so many years ago.
The 35th anniversary of the publication of RFCs 1034 and 1035 reminds us of the contributions that the DNS has made to the growth and scale of what we know today as “the internet.” That’s a moment worth celebrating.
The post Celebrating 35 Years of the DNS Protocol appeared first on Verisign Blog.
This article originally appeared in The Domain Name Industry Brief (Volume 18, Issue 3)
Earlier this year, the Internet Engineering Task Force’s (IETF’s) Internet Engineering Steering Group (IESG) announced that several Proposed Standards related to the Registration Data Access Protocol (RDAP), including three that I co-authored, were being promoted to the prestigious designation of Internet Standard. Initially accepted as proposed standards six years ago, RFC 7480, RFC 7481, RFC 9082 and RFC 9083 now comprise the new Standard 95. RDAP allows users to access domain registration data and could one day replace its predecessor the WHOIS protocol. RDAP is designed to address some widely recognized deficiencies in the WHOIS protocol and can help improve the registration data chain of custody.
In the discussion that follows, I’ll look back at the registry data model, given the evolution from WHOIS to the RDAP protocol, and examine how the RDAP protocol can help improve upon the more traditional, WHOIS-based registry models.
In 1998, Network Solutions was responsible for providing both consumer-facing registrar and back-end registry functions for the legacy .com, .net and .org generic top-level domains (gTLDs). Network Solutions collected information from domain name registrants, used that information to process domain name registration requests, and published both collected data and data derived from processing registration requests (such as expiration dates and status values) in a public-facing directory service known as WHOIS.
From Network Solution’s perspective as the registry, the chain of custody for domain name registration data involved only two parties: the registrant (or their agent) and Network Solutions. With the introduction of a Shared Registration System (SRS) in 1999, multiple registrars began to compete for domain name registration business by using the registry services operated by Network Solutions. The introduction of additional registrars and the separation of registry and registrar functions added parties to the chain of custody of domain name registration data. Information flowed from the registrant, to the registrar, and then to the registry, typically crossing multiple networks and jurisdictions, as depicted in Figure 1.
Over time, new gTLDs and new registries came into existence, new WHOIS services (with different output formats) were launched, and countries adopted new laws and regulations focused on protecting the personal information associated with domain name registration data. As time progressed, it became clear that WHOIS lacked several needed features, such as:
The IETF made multiple attempts to add features to WHOIS to address some of these issues, but none of them were widely adopted. A possible replacement protocol known as the Internet Registry Information Service (IRIS) was standardized in 2005, but it was not widely adopted. Something else was needed, and the IETF went back to work to produce what became known as RDAP.
RDAP was specified in a series of five IETF Proposed Standard RFC documents, including the following, all of which were published in March 2015:
Only when RDAP was standardized did we start to see broad deployment of a possible WHOIS successor by domain name registries, domain name registrars and address registries.
The broad deployment of RDAP led to RFCs 7480 and 7481 becoming Internet Standard RFCs (part of Internet Standard 95) without modification in March 2021. As operators of registration data directory services implemented and deployed RDAP, they found places in the other specifications where minor corrections and clarifications were needed without changing the protocol itself. RFC 7482 was updated to become Internet Standard RFC 9082, which was published in June 2021. RFC 7483 was updated to become Internet Standard RFC 9083, which was also published in June 2021. All were added to Standard 95. As of the writing of this article, RFC 7484 is in the process of being reviewed and updated for elevation to Internet Standard status.
Operators of registration data directory services who implemented RDAP can take advantage of key features not available in the WHOIS protocol. I’ve highlighted some of these important features in the table below.
| RDAP Feature | Benefit |
| Standard, well-understood, and widely available HTTP transport | Relatively easy to implement, deploy and operate using common web service tools, infrastructure and applications. |
| Securable via HTTPS | Helps provide confidentiality for RDAP queries and responses, reducing the amount of information that is disclosed to monitors. |
| Structured output in JavaScript Object Notation (JSON) | JSON is well-understood and tool friendly, which makes it easier for clients to parse and format responses from all servers without the need for software that’s customized for different service providers. |
| Easily extensible | Designed to support the addition of new features without breaking existing implementations. This makes it easier to address future function needs with less risk of implementation incompatibility. |
| Internationalized output, with full support for Unicode character sets | Allows implementations to provide human-readable inputs and outputs that are represented in a language appropriate to the local operating environment. |
| Referral capability, leveraging HTTP constructs | Provides information to software clients that allow the client to retrieve additional information from other RDAP servers. This can be used to hide complexity from human users. |
| Support of standardized authentication | RDAP can take full advantage of all of the client identification, authentication and authorization methods that are available to web services. This means that RDAP can be used to provide the basic framework for differentiated access to registration data based on attributes associated with the user and the user’s query. |
Verisign’s RDAP service, which was originally launched as an experimental implementation several years before gaining widespread adoption, allows users to look up records in the registry database for all registered .com, .net, .name, .cc and .tv domain names. It also supports Internationalized Domain Names (IDNs).
We at Verisign were pleased not only to see the IETF recognize the importance of RDAP by elevating it to an Internet Standard, but also that the protocol became a requirement for ICANN-accredited registrars and registries as of August 2019. Widespread implementation of the RDAP protocol makes registration data more secure, stable and resilient, and we are hopeful that the community will evolve the prescribed implementation of RDAP such that the full power of this rich protocol will be deployed.
You can learn more in the RDAP Help section of the Verisign website, and access helpful documents such as the RDAP technical implementation guide and the RDAP response profile.
The post Industry Insights: RDAP Becomes Internet Standard appeared first on Verisign Blog.
FreshRSS 