Part I: How I Learned to Stop Worrying and Love the RFCs

In a two-part blog series, we’re going to take a wild and whimsical journey into the world of internet protocols. 

In this first post, we’ll explore the sacred tomes known as RFCs, wherein eccentric geniuses laid the foundations for everything online. We’ll also dive into DNS, the king of internet naming. Then, in our second post (coming next week), we’ll take a close look at SMTP, the court jester of email delivery, and how DNS and SMTP became an indomitable cybercrime-fighting team through innovations like SPF, DKIM, and DMARC. Through it all, we’ll explore how RFCs were used to both create and improve these two foundational internet protocols and, in turn, power our modern, digital existence.

But First, a Quick Review of a Few Acronyms

RFC – Requests for Comments

TCP – Transmission Control Program

IP – Internet Protocol

HTTP – Hypertext Transfer Protocol

DNS – Domain Name System

SMTP – Simple Mail Transfer Protocol

TLD – Top-Level Domain

SPF – Sender Policy Framework

DKIM – DomainKeys Identified Mail

DMARC – Domain-based Message Authentication Reporting and Conformance

RFCs: The Sacred Scrolls of the Internet Age

Before we get into DNS and SMTP, let’s talk about the backbone of the internet: RFCs. These documents are the lifeblood of the online world we know and love.

What is an RFC? 

In the earliest days of the internet, the tech innovators who came together to build the global computer network agreed there should be rules and standards to guide their work (and the work of future internet contributors). Thus, they would transcribe their great ideas onto hallowed documents called Requests for Comments (RFC). These sacred scrolls contained the rules that would govern everything in the online realm – from how data packets are formatted to how emails are composed. Without them, the internet would be utter chaos.

But creating an RFC wasn’t as simple as transcribing one’s brilliant thoughts. No, it was a process that called for:

1. The idea keeper to submit their proposal to the Internet Engineering Task Force;
2. The task force to consecrate the document by assigning it an RFC number; and
3. The release of the RFC into the wild for the internet community to study, scrutinize, and critique.

Only after enduring this trial by fire, could (and can) an RFC be adopted as an internet standard. It’s a chaotic and delightfully nerdy process in which proposed ideas get tossed around, debated, and refined until they’re polished enough to become official RFCs – and it’s beautiful to behold. 

Famous RFCs 

While you may be thinking RFCs don’t seem at all exciting, some of these documents are truly fascinating (or, at the very least, they’ll make you chuckle).

For example, RFC 3514 is all about the “Evil Bit,” a tongue-in-cheek proposal to add a special flag to internet protocols that would allow for efficient and automated censorship. Or, how about RFC 1149, which specifies the ultimate in network performance: transmitting data via carrier pigeon?

Here are a few of the foundational RFCs that helped shape the internet as we know it today:

RFC 675 – Specification of Internet Transmission Control Program (1975): This early RFC defined the Transmission Control Program (TCP), which would later become the TCP/IP protocol suite that serves as the backbone of internet communications.

RFC 793 – Transmission Control Protocol (1981): This RFC is the official specification for TCP, one of the core internet protocols that ensures reliable data transmission. It was built upon the groundwork laid in RFC 675.

RFC 791 – Internet Protocol (1981): This RFC defined the Internet Protocol (IP), which handles addressing and routing of data packets across the internet. Together with TCP, it forms the TCP/IP protocol suite.

RFC 822 – Standard for the Format of ARPA Internet Text Messages (1982): While not the first email standard, this RFC codified the syntax and formatting rules for email messages, paving the way for SMTP and other email protocols.

RFC 1945 – Hypertext Transfer Protocol, HTTP/1.0 (1996): The original specification for HTTP, the protocol that powers the World Wide Web and allows us to browse websites as we know them today.

RFC 5246 – The Transport Layer Security, TLS Protocol Version 1.2 (2008): TLS, the successor to the venerable SSL protocol, provides encryption and secure communications over the internet. This RFC defined the widely used TLS 1.2 version.

These are just a few examples, but the list of foundational RFCs is extensive. Each one builds upon the work of those that came before it, shaping the internet’s architecture and functionality over decades of collaboration and refinement.

In my opinion, the RFCs that defined DNS (RFC 1034 and 1035) and SMTP (originally RFC 821) are the real stars of the show. Without them, we’d be lost in a sea of IP addresses, unable to send emails or access websites by their friendly domain names. My thanks to these quirky RFC authors. Their obsessive attention to detail and love for well-defined standards are what make the internet work like a well-oiled (if slightly eccentric) machine.

The Birth of DNS 

In the early 1980s, the internet was in its infancy. The few sites in existence were tracked using a single, centralized master HOST file maintained by the Stanford Research Institute Network Information Center (NIC); the system was created in 1974 with RFC 625. But as more sites started popping up like digital rabbits, it became obvious that a new way of organizing them was needed. In fact, it was the complex problem of efficient email routing that caused a group of Advanced Research Projects Agency Network (ARPANET) and other experts to meet and discuss a solution for email relaying. And thus, the brilliantly decentralized and hierarchical Domain Name System (DNS) was conceived. 

A special shout out to Paul Mockapetris and Jon Postel, the coding royalty behind RFCs 1034 and 1035. They established the hierarchies of top-level domains like .com as a starting point for delegation of queries, and the need for an administrative entity for registering these names (along with the necessity for the distribution of individual name servers). 

How Does DNS Magic Happen? 

When you type a domain into your browser, it’s like shouting into the Matrix, “Where does Facebook.com live?” (for example).

First, your trusty resolver does a recursive scan, passing the question from the root DNS servers down to the .com overlords to find the dudes in charge of facebook.com’s realm.

Next, in an iterative fury, the root servers will be like, “Not my problem, ask THESE guys. They know .com.” Those guys then say “Hey, I know .com, but it looks like those guys OVER THERE are the ones responsible for facebook.” Until finally, the real facebook.com keymasters are like, “Oh, you want 123.45.67.89.”

Who are these domain keymasters? 

• The all-powerful Root Servers: The root servers serve the root zone, the global list of all top-level domains, like .com, .net and .org, as well as country-code domains like .us, .uk, .cn, etc. The root zone, controlled by the Internet Assigned Numbers Authority (IANA), which is part of the Internet Corporation for Assigned Names and Numbers (ICANN), also includes international top-level domains containing unicode characters. 
  
  There are 13 geographically dispersed root name servers, but each one has many copies worldwide and they use Anycast routing to guarantee fast responses.
  
• The Top-Level Domain (TLD) administrators (.com, .org, etc): ICANN has delegated the authority to administer the top level domains to several public and private organizations. For example Verisign manages the .com and .net TLDs, and individual governments can decide who manages their dedicated TLDs.
  
• The Authoritative Name Servers: Authoritative Name Servers are the ones most commonly used by the public. Services like Cloudflare, Route53, and DNSimple operate authoritative name servers, but anyone can run their own. 

DNS Records

DNS servers store DNS records, and there are a number of sacred record types, including:

• A – IP address
• CNAME – Canonical name (Alias)
• MX – Mail exchanger
• NS – Name server
• TXT – Arbitrary text
• SRV – Services
• PTR – Reverse DNS
• SOA – Start of Authority

And with more than 30 record types defined, this is just scratching the surface of the great DNS library. Thankfully, the DNS administrators have dedicated their cyber-lives to steadfastly maintaining this dizzying system of domain mappings, so the rest of us can browse and email in peace.

Putting It All Together

So when your browser requests a page from, say, developers.facebook.com, your local computer’s DNS resolver reaches out to other DNS servers to find the address you are looking for. Most DNS servers maintain caches, so they only reach out to other servers if they don’t know part of the chain. For instance, a new DNS server with no cache already knows the addresses of the root name servers, so it will connect to one of them on port 53 (hence the name of AWS’s Route53) and get the address of the server responsible for the .com TLD. That TLD server will provide the IP for the server responsible for facebook.com, and THAT server will give you the IP address you requested. 

Here’s the incredible part: this system results in a fast, global, decentralized, distributed, hierarchical, fault-tolerant database of name/address mappings that is STILL the basis for all internet routing, and it was created in the early 1980s!

As a reminder, in week’s post, we’ll take a look at SMTP, and how DNS and SMTP became an indomitable cybercrime-fighting team through innovations like SPF, DKIM, and DMARC. We’ll also continue to explore the role of RFCs in both creating and improving these foundational internet protocols.

---

Dan Horne request for comment RFC SMTP