Something has been lost. Before algorithmic timelines, message length restrictions and mass surveillance there was a more robust world. It’s a distributed world that still lives behind the centralized allure of social networks. It’s a world where every person owns a small part of the internet, where they control their medium and communicate freely.

I’m referring to the domain name system and email. You may think that you take full advantage of them, but I suspect you don’t. This is a guide to going back to the brave old world — the original social network.

Although subsequently extended, email (SMTP) and DNS were created in 1982 and 1983 respectively in a form still recognizable today. RFC821 defines SMTP and RFC882 soon followed because “mail system implementers long ago recognized the impossibility of centralizing mailbox names, they have also created an increasingly large and irregular set of methods for identifying the location of a mailbox.”

Email and DNS appeared early in internet history, by comparison ARPANET switched to TCP/IP later than both of them, on January 1st 1983. Looking at it this way if you’re still digitally sharecropping on a MediumTubeTwitBook account with no domain of your own you’re basically thirty-three years behind the times.

Let’s change that.

DNS: the foundation of your identity

Leasing a domain name and having full control of its resource records is the basis of your free expression online. If you don’t yet have your own domain it’s worth finding one. Domainr allows you quickly search for available domains by word or phrase across multiple top level domains.

Notice I said leasing rather than owning a domain. This is because nobody owns domains in perpetuity. We may at most lease them for up to ten years from one of the top-level domain registry operators. Each registry holds records for a different top-level domain such as .com, .org, or … .pizza (that last from Donuts Inc, self-described as “one of the world’s most innovative and creative companies.”)

There’s one more twist in the domain rental story. Individuals cannot lease domains directly from a registry, but must do so through an ICANN accredited registrar. While you can become your own registrar, doing so costs thousands of dollars and does not give any extra ownership over your registered domains.

After you’ve found an available domain, it’s time to register it. Head over to GoDaddy, just kidding, pick a reputable registrar like Namecheap, DNSimple, Gandi, or many others. Note that each registrar works only with certain top-level domains. Some TLDs are less straightforward to register (such as .do which involves faxing a letter in Spanish to the Dominican Republic).

You’re the king of your zone

With domain lease registration complete you now control a DNS “zone.” This is important because the zone ties together records that manage your web and email presence along with settings to prevent people from impersonating you.

To understand these settings let’s review more about how DNS works. Suppose a browser wishes to contact news.ycombinator.com (and no results are cached along the way). The operating system begins by talking to a DNS it discovered when connecting to an internet service provider, or a user-specified DNS such as OpenDNS or Google. These intermediaries are called recursive servers because they pass on the request recursively to more specific authorities. If the host name is not present in its cache the recursive DNS uses a systematic process to resolve it.

Let’s pretend we’re a recursive DNS server. First invert the domain name, so news.ycombinator.com becomes:

.com.ycombinator.news

This forms a chain of specificity: ., .com, .com.ycombinator, .com.ycombinator.news. The first domain which I wrote as . is the root DNS, and technically has an empty string for its name. We’ll start at the root.

Who runs the root domain name server and how do we know where to find it in the first place? There are several actually, and they have old well-known IP addresses listed in InterNIC’s root hints file. New DNS servers are bootstrapped with this information.

The oldest root node of all runs on 198.41.0.4 (and has done so since 1991). Although it’s a single IP address it actually routes to clusters of servers in five locations across the world using IP Anycast. Let’s ask it about the other root name servers (NS is the code for a nameserver record):

dig @198.41.0.4 . NS

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	199.7.91.13
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	198.97.190.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	518400	IN	AAAA	2001:500:84::b

The answers section shows there are thirteen addresses, each one [a-m].root-servers.net. The “additional” section includes IP addresses for these hosts (called GLUE records) as a shortcut to avoid a second query. Each of these IP addresses uses Anycast to map the address among many computers. Here’s a K root server in Amsterdam:

Let’s talk to it, or a least one of the computers in its K class! What happens if we ask the root server to tell us the IP of our desired host? (The A record below stands for “Address” and will be the IP of the actual server.)

dig @k.root-servers.net news.ycombinator.com A

;; QUESTION SECTION:
;news.ycombinator.com.		IN	A

;; AUTHORITY SECTION:
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.	172800	IN	A	192.5.6.30
a.gtld-servers.net.	172800	IN	AAAA	2001:503:a83e::2:30
b.gtld-servers.net.	172800	IN	A	192.33.14.30
b.gtld-servers.net.	172800	IN	AAAA	2001:503:231d::2:30
c.gtld-servers.net.	172800	IN	A	192.26.92.30
d.gtld-servers.net.	172800	IN	A	192.31.80.30
e.gtld-servers.net.	172800	IN	A	192.12.94.30
f.gtld-servers.net.	172800	IN	A	192.35.51.30
g.gtld-servers.net.	172800	IN	A	192.42.93.30
h.gtld-servers.net.	172800	IN	A	192.54.112.30
i.gtld-servers.net.	172800	IN	A	192.43.172.30
j.gtld-servers.net.	172800	IN	A	192.48.79.30
k.gtld-servers.net.	172800	IN	A	192.52.178.30
l.gtld-servers.net.	172800	IN	A	192.41.162.30

Notice it doesn’t have an answer section. This server doesn’t have the authority to return the answer, but it suggests we contact other servers which can tell us more about hosts in .com. It knows these servers are relevant because our desired host name ends in .com. The suggested name servers have names such as a.gtld-servers.net. There are thirteen of these as well.

dig @k.gtld-servers.net news.ycombinator.com A

;; QUESTION SECTION:
;news.ycombinator.com.		IN	A

;; AUTHORITY SECTION:
ycombinator.com.	172800	IN	NS	ns-225.awsdns-28.com.
ycombinator.com.	172800	IN	NS	ns-556.awsdns-05.net.
ycombinator.com.	172800	IN	NS	ns-1914.awsdns-47.co.uk.
ycombinator.com.	172800	IN	NS	ns-1411.awsdns-48.org.

;; ADDITIONAL SECTION:
ns-225.awsdns-28.com.	172800	IN	A	205.251.192.225
ns-556.awsdns-05.net.	172800	IN	A	205.251.194.44

This server too lacks the authority to give us an answer, but it directs us to two name servers (NS records) for ycombinator.com. We’re close now.

dig @ns-225.awsdns-28.com news.ycombinator.com A

;; QUESTION SECTION:
;news.ycombinator.com.		IN	A

;; ANSWER SECTION:
news.ycombinator.com.	300	IN	CNAME	news.ycombinator.com.cdn.cloudflare.net.

;; AUTHORITY SECTION:
ycombinator.com.	172800	IN	NS	ns-1411.awsdns-48.org.
ycombinator.com.	172800	IN	NS	ns-1914.awsdns-47.co.uk.
ycombinator.com.	172800	IN	NS	ns-225.awsdns-28.com.
ycombinator.com.	172800	IN	NS	ns-556.awsdns-05.net.

We’ve arrived. This time there is an answer section. Because this nameserver is able to provide answers about the ycombinator.com domain, it is authoritative, and controls this zone. Remember that term from earlier? When you register a domain you’ll control your own zone.

But back to the response. Rather than the A record we requested, it turns out there is a CNAME, i.e. a hostname alias. The real server(s) hide behind CloudFlare which helps cache their assets and protect the site from attacks. The host listed in the CNAME requires another round of DNS lookups…

In reality this process goes very quickly because DNS servers cache results. If I dig the news site through my regular DNS it returns the result immediately in 32ms. I guess it proves that I and other people sharing this DNS server have requested the address recently. (We should stop looking at the news and get back to work!)

Domain registration, revisited

Now that you know more about how DNS works I can reveal the double nature of domain registrars. Consumer facing registrars do two distinct things: host a nameserver that you can configure through a web interface and add NS records to the gtld-servers. (Sometimes other records as well, like A records for glue and DS for DNSSEC.)

By default those NS records point at the registrar-hosted nameserver (usually more than one server, geographically distributed). It’s actually very convenient. However you can override the choice of nameserver, possibly even running your own. If you’d like to go down that path check out the book DNS and BIND. Note that proof of Unix neckbeard is required for the purchase of this book.

To check you domain for optimal configuration try the free web based intoDNS tool. Along with test results it helpful links to relevant sections from RFCs, which are a good way to learn more about the standards.

Securing your DNS records

The early web was a trusting place, connecting cooperative research institutions. When it emerged into the messy world outside it ran into security abuses. In the nineties people began efforts to fix the problems, but it took many years before they settled on a workable solution that could reach internet scale. Finally on July 15, 2010 the dominant approach, DNSSEC, went live on the root servers. For an interesting bit of history check out the DNSSEC Diaries which discusses some of the engineering tradeoffs of its design.

Today the DNSSEC extension can authenticate your zone, thereby protecting your nameserver records. However it requires your cooperation. If you’re using a registrar hosted nameserver then there’s usually a button to enable DNSSEC and it’s as easy as that. It’s best to check that a registrar supports DNSSEC in their hosted nameserver before signing up with them. If you’re running your own nameserver then you have more work to do.

To use DNSSEC each participating zone publishes a public key in a DNSKEY record, and registers a DS key in the parent zone (often the top level domain servers). For example, let’s inspect Hacker News’ record:

dig news.ycombinator.com.cdn.cloudflare.net DNSKEY

;; QUESTION SECTION:
;news.ycombinator.com.cdn.cloudflare.net. IN DNSKEY

;; AUTHORITY SECTION:
cloudflare.net.		3600	IN	SOA	ns1.cloudflare.net. dns.cloudflare.com. 2021398090 10000 2400 604800 3600

Verisign’s DNSSEC Debugger is a good way to visualize the security chain. We can see that this chain checks out, although at the time of this writing the base domain ycombinator.com uses an Amazon Route 53 nameserver which does not support DNSSEC.

In general terms an individual DNSKEY signature is validated by following a chain of signatures to a key which is trusted for some extra-protocol reason. ICANN, as IANA Functions Operator, is responsible for the publication of trust anchors for the root zone.

The authenticity of the root nodes rely on a trusted key called the trust anchor. Every so often this key is replaced as a precaution, and a coalition of people from all over the world cryptographically signs the new key in a ceremony with mind-boggling levels of security. We’re talking retinal scans, many live camera angles, multiple safes…Read how it happens.

Harnessing the cockroach

Email, affectionately called the “cockroach of the internet,” is designed to scurry from server to server. It’s resilient and based on an open interoperable protocol. By leasing a domain you can fully own your inbox, and can communicate with any other email account no matter how it is hosted.

Unfortunately many people have declined the privilege of email ownership and instead lock into a free mail server from Google or other providers. Stop for a moment and think about any other aspect of your life. When is ongoing service from a stranger ever free? It’s not. Free email service should creep you out, but somehow we’ve come to believe that things are different online. Well “online” just means a bunch of computers in random rooms, so no, it’s not different.

On the other hand when you lease a domain, your nameserver allows you to designate (and later change) the server you use to send and receive email. As to the mail server itself, you can operate your own or choose an honest managed server for a fee.

The easiest way to self-host a mail server is probably Mail-in-a-Box, but easy is a relative term. Because of spammers activities over the years email servers are distrustful of new senders. It can be easier to pay a company to handle the complexity for you, companies such as FastMail, KolabNow, Posteo or many others.

You use the MX record in your DNS zone to direct emails to your email provider (the provider will provide you the settings to use). As mentioned this means you’re free to change providers while continuing to use the same email address. You can feel comfortable trying a provider or a homemade solution and seeing how you like it.

Sadly using a respectful email service doesn’t dramatically improve the privacy of your mail because so many of the people you write are still on Gmail. Google will receive and algorithmically strip-mine your messages as usual. But don’t despair, we will take back the web we lost one person at a time. That’s why you’re reading this now.

Preventing “Joe Jobs” (email impersonation)

An email consists of header records and the message itself. Senders are free to fill out the records however they want, including setting the “From” header to look like another person. The deception isn’t immediately obvious to most recipients. As with DNS, email was designed in a simpler more trusting environment.

Luckily there are DNS records you can set to give receiving mail servers clues to know when to reject fraudulent emails. The first is called Sender Policy Framework (SPF). It’s a TXT record with a certain format which lists the servers that you authorize to send mail claiming to be from your domain.

Let’s look at ycombinator again as an example:

$ dig ycombinator.com TXT +short

"v=spf1 include:_spf.google.com include:mailgun.org include:_spf.createsend.com -all"

We can see they have authorized Gmail for their personal communication, Mailgun for programmatic replies from their application process, and “createsend.com” which appears to be a backend for CampaignMonitor, which manages their newsletters. Any other servers sending mail claiming to be from ycombinator can be easily checked against this list. The -all specifies a hard failure for servers not on the list. More lenient settings are possible.

The next email problem we have to confront is intermediate servers modifying our messages or headers. DKIM (DomainKeys Identified Mail) was designed to prevent this. The high-level idea is that the sending server cryptographically signs the content of an email and includes the signature in a header named unsurprisingly, Dkim-Signature. Simultaneously the public key for this signature is published – guess where – in a TXT record on the sending domain. If the signature matches then nobody along the line has changed anything. Pair this with DNSSEC to authenticate the records as a whole and life is good.

Or is it?

What if a server along the way changes the message body or attachments and also removes the DKIM signature altogether? To the receiver it would look like a normal unsigned message from the correct sender. DMARC is the final piece of the puzzle that complements the other two security measures. It’s another DNS record that you can publish to specify your email policy. For instance you can specify that all your legit messages will include DKIM and that the receiver should reject any messages lacking it. DMARC also tells other servers where to report attempted abuse of your email. The settings are pretty complicated, so try this wizard which explains them.

Raise your sights

If you’ve configured all the above then you control your long-term identity online. You can speak freely on your own web property and use your own artistic style. You can send and receive emails free from impersonation. But what about a wider reach?

Networks like Twitter are popular because you can send updates to a large following. How can you do this on the “original social network?” Blog posts are certainly public, but they don’t push notifications to anyone. RSS fills the role to some degree but it’s not nearly as popular as email.

How can we build larger scale communication on top of email? The two models are the newsletter (one-to-many) and the mailing list (many-to-many).

If you want to dip your toe into this there are two simple services to try, the first is simplelists. Its terms of use and privacy policy look really good, and like any honest service they charge money after a free trial period. Their support page makes it sound like you can export your list if you want to leave, although the process is not clear.

The second service, TinyLetter, is for mailing lists and is more questionable. It is free and is dead simple to use. Remember my earlier warning about free services! TinyLetter’s terms of use reveal it is basically a lure to help populate MailChimp’s Email Genome Project, a “service that uses software to constantly analyze millions of email lists and billions of email addresses, and uncover stories and trends that are hidden in the data.” If you’re cool with that you could start your list on TinyLetter and export the contacts when you’re ready to break free. At least you’re using email and not a proprietary app. Note that TinyLetter also sends tracking beacons to your subscribers to detect when and where they read their email, which is typical but pretty offensive.

Another thing about TinyLetter is that the messages aren’t coming entirely from you. Your email address ends up as a Reply-To header and not really the From address. I treat my own mailing list as an extension of my regular emails. It sends from literally the same address as my normal email. I enjoy it when people reply to me for a discussion. When writing list messages I don’t think of it as a weirdo marketing brochure, but as an email to my friends that happens to have a whole lot of CC’s.

If you want to fully control not only your regular email but also a mailing list then you have to self-host. This is a fascinating topic, and one I will describe in another article because this one is getting rather long. We’ll talk about the life of an email, its headers, bounce handling, DMARC alignment, and other factors of deliverability. You’ll also learn about Google’s algorithmic adjustment in 2013 and its affects on how their users perceive email.

Until then, get yourself a domain and join me on the original social network!