Dan Phiffer Dan Phiffer is an Internet enthusiast based in Troy, NY

Configuring DNS-over-TLS on macOS

Note: this post has been updated to fix a mistake in the knot-resolver configuration. The earlier version would not have provided the privacy it purported to. I regret the error.

Until yesterday I hadn’t thought too much about DNS metadata leakage. Here’s how it works: your computer sends out a request to resolve a DNS hostname, let’s say “topsecretwebsite.example,” and your DNS server responds back with its IP address in a way that’s easy to eavesdrop on. It’s wild that the Internet works like this by default.

What happened yesterday is a company called CloudFlare (a popular and free content delivery network) announced a new DNS service at the IP address (Yes it launched on April 1, no it’s not a joke.) The service supports a couple of interesting privacy protecting options: DNS-over-HTTPS and DNS-over-TLS. Those technologies don’t guarantee your DNS lookups are accurate (check out DNSSEC for that), or that the DNS provider won’t someday betray you, they just make it’s harder to collect metadata by listening in on DNS’s cleartext port 53.

I asked for pointers on Twitter, for how to set this up, and landed on these notes from Daniel Kahn Gillmor (aka dkg) from a workshop he offered at the most recent Internet Freedom Festival. (Thanks for the pointer Jen!)

This all got me to set up my own DNS resolver on my laptop, which runs macOS 10.13.4.

  • I’m running a local instance of knot-resolver (the same software that runs CloudFlare’s
  • macOS is configured to lookup DNS at on the usual port 53
  • My local knot-resolver (aka kresd) is configured to send requests upstream to over TLS

1. Install knot-resolver

I used Homebrew to install.

brew install knot-resolver

Then I installed a service to run it on startup.

sudo brew services start knot-resolver

2. Configure knot-resolver

Then I edited the config file.

nano /usr/local/etc/kresd/config

I added the following to the end of the file:

policy.add(policy.all(policy.TLS_FORWARD({{'', hostname=''}})))

3. Restart kresd

Restart the service for your change to take effect.

sudo brew services restart knot-resolver

4. Test the “before”

Now you want to configure your system to use the local DNS service. First, see how it responds before we add our own DNS server into the mix.


You should see some results resolving to its IP address, with this detail at the bottom about where the results came from (yours will be different).

;; From in 36.8 ms

Basically my computer just broadcast in cleartext, over UDP port 53, “hey do you know where I can find PLANNEDPARENTHOOD.COM?” This happens each time you load up a website. It happens that is a wifi router in my apartment under my control, but that request still gets passed to other DNS servers upstream, all in cleartext.

5. Configure macOS

Now go to Apple Menu → System Preferences → Network → Advanced → DNS and add as your DNS server.

6. Test the “after”

Try kdig again. Now you should see your local address at the bottom.

;; From in 149.5 ms

You’ll get the same IP address result, but now delivered to you with the privacy of TLS encryption. Hooray!

What else?

If that doesn’t work for you, you may want to check out the log file /usr/local/var/log/kresd.log for errors.

Also consider using other privacy-protecting DNS services beyond I applaud CloudFlare for drawing attention to how we can improve our network privacy, but if we all use the same service it creates a single point of failure. Alternatively you could go with, or, or (dkg’s own service), or something else.

You should also know there are situations where you need to use a specific DNS server. For example, if you are on a corporate network it might rely on hostnames that aren’t hosted anywhere but on the internal DNS servers. So realize that adjusting your DNS settings means things may break in the future. Try to remember this for when you end up with mysterious network issues in the future!

Thanks to Daniel Kahn Gillmor for providing feedback on a draft of this post and to Pavel Zhovner who wrote with a correction to an earlier version of this post.

Why you should learn to program your computer

This is an essay I wrote for a one-off newspaper published by the Trade School folks. I haven’t found any trace of it online, but I bet a PDF version will materialize at some point.

An unusual book was published in 1974 called Computer Lib/Dream Machines. It has an oversized magazine format and two front covers. The two sides read inward to the center page, each side rotated 180° to the other. On the Computer Lib side, above a crudely-drawn clenched fist, reads the subtitle: You can and must understand computers NOW. I like the imperative nature of the phrase, even all these years later.

The book isn’t written by a computer scientist. Its author, Ted Nelson, isn’t a “technical person” so to speak, he has degrees in sociology and philosophy. He is a kind of über-generalist:

People keep pretending they can make things deeply hierarchical, categorizable and sequential when they can’t. EVERYTHING IS DEEPLY INTERTWINGLED. In an important sense there are no “subjects” at all; there is only all knowledge, since the cross- connections among the myriad topics of this world simply cannot be divided up neatly.

Nelson also coined the term “hyptertext” and continues to work on Xanadu, an ambitious (but tragically unpopular) hypertext system technically still in competition with the World Wide Web. I think of him, fondly, as the web’s crazy uncle. I appreciate his open resistance to the conventions of the web, even if my own career building websites is largely based on those conventions.

It’s hard to overstate the ubiquitous role the web now plays in our lives. The undergraduates I teach have grown up with access to Facebook and Google, these things must feel timeless to them. However, the internet as a whole is a fairly recent creation. It’s the result of very deliberate choices reflected in infrastructure and code. It’s easy to overlook how that hardware and software actually operates on our data.

As Lawrence Lessig has argued in Code, “we can build, or architect, or code cyberspace to protect values that we believe are fundamental. Or we can build, or architect, or code cyberspace to allow those values to disappear.” Setting aside Lessig’s unfashionable use of the word cyberspace, his point is an important one. It’s echoed more recently by Douglas Rushkoff in Program or Be Programmed:

Throughout the twentieth century, we remained blissfully ignorant of the real biases of automotive transportation. We approached our cars as consumers, through ads, rather than as engineers or, better, civic planners. We gladly surrendered our public streetcars to private automobiles, unaware of the real expenses involved.

Like global warming and urban sprawl, the dangers of centralized, corporate control over our mediated lives might seem daunting, inevitable even. It’s tempting to simply make due with those tools already at hand, to let professionals make the hard decisions about the software we rely on. The principle of intertwingularity suggests otherwise—your individual preferences and knowledge are fundamentally connected to the technologies where they become manifested. The capacity to write code is deeply intertwingled with what that software can produce.

Granted, the progress you can expect to make learning to program computers will be slow. It may take years before you build anything close to useful. Even so, the patterns of thought developed through understanding code will help you better negotiate the strange currents of our hypermediated world. The important first step is understanding why so that you will want to find out how. The second step is deciding on a project to undertake. The rest is a cyclical process of typing, befuddlement, and exhilaration when you finally understand how it works.

hello, archive.org_bot