How to keep your ISP’s nose out of your browser history with encrypted DNS

Using Cloudflare’s 1.1.1.1, other DNS services still requires some command-line know-how

Encrypting DNS traffic between your device and a "privacy-focused" provider can keep someone from spying on where your browser is pointed or using DNS attacks to send you somewhere else.
Westend61 / Getty Images
The death of network neutrality and the loosening of regulations on how Internet providers handle customers' network traffic have raised many concerns over privacy. Internet providers (and others watching traffic as it passes over the Internet) have long had a tool that allows them to monitor individuals' Internet habits with ease: their Domain Name System (DNS) servers. And if they haven't been cashing in on that data already (or using it to change how you see the Internet), they likely soon will.

DNS services are the phone books of the Internet, providing the actual Internet Protocol (IP) network address associated with websites' and other Internet services' host and domain names. They turn arstechnica.com into 50.31.169.131, for example. Your Internet provider offers up DNS as part of your service, but your provider could also log your DNS traffic—in essence, recording your entire browsing history.

"Open" DNS services provide a way of bypassing ISPs' services for reasons of privacy and security—and in some places, evading content filtering, surveillance, and censorship. And on April 1 (not a joke), Cloudflare launched its own new, free high-performance authoritative DNS service designed to enhance users' privacy on the Internet. This new offering also promised a way to hide DNS traffic completely from view—encryption.

Advertisement
Named for its Internet Protocol address, 1.1.1.1 is the result of a partnership with the research group of APNIC, the Asia-Pacific Internet registry. While it's also available as an "open" conventional DNS resolver (and a very fast one at that), Cloudflare is supporting two encrypted DNS protocols.

While executed with some unique Cloudflare flare, 1.1.1.1 isn't the first encrypted DNS service by any means—Quad9, Cisco's OpenDNS, Google's 8.8.8.8 service, and a host of smaller providers support various schemes to encrypt DNS requests entirely. But encryption doesn't necessarily mean that your traffic is invisible; some encrypted DNS services log your requests for various purposes.

Cloudflare has promised not to log individuals' DNS traffic and has hired an outside firm to audit that promise. APNIC wants to use traffic data to point to the IP address, which has the unfortunate legacy of being a dumping ground for "garbage" Internet traffic, for research purposes, according to APNIC's Geoff Huston. But APNIC won't have access to the encrypted DNS traffic in this case, either.

For users, taking advantage of encrypted DNS services from Cloudflare or any other privacy-focused DNS services is not as easy as changing a number in network settings. No operating system currently directly supports any of the encrypted DNS services without the addition of some less-than-consumer-friendly software. And not all of the services are created equally in terms of software support and performance.

But with consumer data as product all over the news as of late, I set out to see just how to get Cloudflare's encrypted DNS service working. And overcome by my inner lab-rat, I ended up testing and dissecting clients for multiple DNS providers using three of the established protocols for DNS encryption: DNSCrypt, DNS over TLS, and DNS over HTTPS. All of them can work, but let me warn you: while it's getting easier, choosing the encrypted DNS route is not something you'd necessarily be able to walk Mom or Dad through over the phone today. (Unless, of course, your parents happen to be a seasoned Linux command-line user.)

Why are we doing this, again?
There are plenty of reasons to want to make DNS traffic more secure. While Web traffic and other communications may be protected by cryptographic protocols such as Transport Layer Security (TLS), almost all DNS traffic is transmitted unencrypted. That means that your ISP (or anyone else between you and the rest of the Internet) can log the sites you visit even when you use another DNS service and use that data for a number of purposes, including filtering access to content and collecting data for advertising purposes.

"We have a 'last mile' problem in DNS," said Cricket Liu, Chief DNS Architect at the network security company Infoblox. "Most of the security mechanisms we have dealt with server-to-server issues. But we have this problem where we have stub resolvers on various operating systems and don't really have anyway to secure them." That's particularly a problem, Liu said, in countries that have a more hostile relationship with the Internet.

Just using a non-logging DNS service helps to some degree. But it doesn't prevent someone from filtering those requests based on content or capturing the addresses within them with packet capture or deep packet-inspection gear. And in addition to simple, passive eavesdropping attacks, there's also the threat of more active attacks against your DNS traffic—efforts by an ISP or a government on the wire to "spoof" the identity of a DNS server, routing traffic to their own server to log or block traffic. Something similar (albeit apparently not maliciously) appears to be happening with AT&T's (accidental) misrouting of traffic to Cloudflare's 1.1.1.1 address, based on the observations of forum posters on DSLReports.

The most obvious way to dodge monitoring is by using a virtual private network. But while VPNs conceal the contents of your Internet traffic, connecting to a VPN might require a DNS request first. And once you've launched a VPN session, DNS requests may occasionally get routed outside of your VPN connection by Web browsers or other software, creating "DNS leaks" that expose which sites you're visiting.

That's where encrypted DNS protocols come in—the DNSCrypt protocol (supported by Cisco OpenDNS, among others), DNS resolution over TLS (supported by Cloudflare, Google, Quad9, and OpenDNS), and DNS resolution over HTTPS (currently supported by Cloudflare, Google, and the adult-content-blocking service CleanBrowsing). Encrypted traffic both ensures that traffic can't be sniffed or modified and that requests can't be read by someone masquerading as the DNS service—eliminating middle-man attacks and spying. Using a DNS proxy for one of these services (either directly on your device or on a "server" inside your local network) will help prevent VPN DNS leaks, since the proxy will always be the fastest-responding DNS server.

That privacy does not come packaged for mass consumption, however. None of these protocols are currently supported natively by any DNS resolver pre-packaged with an operating system. All of them require the installation (and probably compilation) of a client application that acts as a local DNS "server," relaying requests made by browsers and other applications upstream to the secure DNS provider of your choice. And while two out of three of the technologies are proposed standards, no option we tested is necessarily in its final form.

So if you choose to dive into encrypted DNS, you will probably want to use a Raspberry Pi or some other dedicated piece of hardware to run it as a DNS server for your home network. That's because you'll find that configuring one of these clients is more than enough hackery. Why repeat the process multiple times when you can just query your local network's dynamic host configuration protocol (DHCP) settings to point everything at one successful installation as a DNS server? I asked myself this question repeatedly as I watched clients crash on Windows and fall asleep on MacOS during testing
Get Crypty
For the sake of completeness, let's start with the original encrypted-DNS option, DNSCrypt. First introduced in 2008 on BSD Unix, DNSCrypt wasn't originally intended as a privacy tool but as a way to protect against DNS "spoofing." However, it can be used as part of a privacy solution—particularly when paired with a non-logging DNS provider. And as DNSCrypt developer Frank Denis pointed out, there are many more DNSCrypt-enabled servers out there than any other sort of encrypted DNS.

"DNSCrypt is a bit more than a protocol," Denis said. "At this point, the community and the projects being worked on define it better than my weekend project protocol." The DNSCrypt community has built easy-to-use clients such as Simple DNSCrypt for Windows and an Apple iOS client called DNS Cloak, making encrypted DNS more accessible to non-technical people. And others have set up an independent network of privacy-aware DNS servers based on the protocol that helps users evade corporate DNS systems.

"DNSCrypt is not about connecting to a specific company," Denis said. "We encourage everybody to run their own servers and make it very cheap and easy to do so. Now that we have privacy-aware resolvers, one thing I'm trying to address right now is privacy-aware content filtering."

For those looking to build a DNSCrypt-enabled DNS server for their whole network, the best client available is DNSCrypt Proxy 2. An earlier version of DNSCrypt Proxy is still available as a package for most of the major Linux distributions, but you'll want to download the binary of the new version directly from the project's GitHub site. There are versions for Windows, MacOS, BSD, and Android as well.

The experience that the DNSCrypt community has built up around privacy is evident in DNSCrypt Proxy. The software is highly configurable, with support for time-access restrictions, pattern-based domain and IP address blacklisting, query logging, and other features that make it a fairly powerful local DNS server. But it requires only the most basic of configuration to get started. There's a sample configuration file, formatted in TOML (Tom's Obvious Minimal Language, created by GitHub co-founder Tom Preston-Werner), which you can simply rename to be the working configuration file before firing DNSCrypt Proxy up.

By default, the proxy uses Quad9's open DNS resolver as a bootstrap to find and obtain a curated list of open DNS services from Github, then it connects to the server with the fastest response time; you can change the configuration and select a service by name if desired. Server information in the list is encoded as a "server stamp" that includes the provider's IP address, public key, whether the server supports DNSSEC, whether the provider keeps logs, and whether the provider blocks some domains. (If you'd rather not depend on a remote file for setup, you can also use a JavaScript-based "stamp calculator" to build your own local static list of servers using this stamp format.)

For my testing with the DNSCrypt protocol, I used Cisco's OpenDNS as the remote DNS service. DNSCrypt's performance was a little slower than conventional DNS on first-time requests, but DNSCrypt Proxy caches results after that. The slowest queries were in the 200-millisecond range, while the average responses were more in the 30-millisecond range. (Your mileage may vary, depending on your ISP, the recursion required to find the domain, and other factors.) On the whole, I didn't notice the speed hit while Web browsing.

The DNSCrypt's main advantage is that it acts the most like "normal" DNS. For good or ill, it uses UDP traffic—on port 443, the same port used for secure Web connections. That makes for relatively fast address resolutions and makes it less likely to be blocked by a network provider's firewall. To further decrease the likelihood of being blocked, you can change the configuration of your client to force it to use TCP/IP for queries (with minimal impact on response times, based on my testing), which makes it look like HTTPS traffic to most network filters—at least on the surface
DNSCrypt traffic revealed, along with DNSCrypt Proxy local traffic. Wireshark says it's HTTPS traffic here, because

I forced it to use TCP. Over UDP, Wireshark thinks it's Chrome's QUIC traffic

On the downside, DNSCrypt doesn't rely on trusted certificate authorities for its encryption—the client has to trust the public signing key issued by the provider. That signing key is used to verify certificates that are retrieved via conventional (unencrypted) DNS requests and used for key exchange, using the X25519 key-exchange algorithm. In some (older) implementations of DNSCrypt, there's a provision for a client-side certificate that can be used as an access-control scheme—allowing them to log your traffic regardless of what IP address you come from and associate it with your account. This isn't used in DNSCrypt 2.

Working with the DNSCrypt protocol as a developer is a bit of a challenge. "DNSCrypt is not particularly well documented, and there are not a lot of implementations of it," said Infoblox's Liu. DNSCrypt Proxy is the only client in active development that we could find, and OpenDNS has stopped supporting development.

DNSCrypt's interesting cryptography choices (at least from the point of view of developers used to web crypto) may spook some developers. The protocol uses Curve25519 (RFC 8032), X25519 (RFC 8031) and Chacha20Poly1305 (RFC 7539) cryptography. One implementation of the X24419 algorithm is labeled as "cryptographic hazmat" in the Pyca Python cryptography libraries because it is so easy to misconfigure. But the underlying cryptographic algorithm DNSCrypt uses, Curve25519, is " one of the easiest elliptic curve to use safely," said Denis.

DNSCrypt was never considered as an Internet Engineering Task Force standard, Denis said, because it was built by volunteers and didn't have corporate sponsorship. Submitting it "would have required dedicated time, as well as defending it at IETF meetings," he said. "I can’t afford that, and neither can other developers who are working on this on their spare time. Virtually all the ratified DNS-related specifications are effectively written by people from a handful companies, always the same year after year. Unless you work at a DNS company, it’s effectively hard to have a say."

While there are a number of DNS services that use DNSCrypt (such as CleanBrowsing, which blocks adult content domains, and Cisco OpenDNS, which blocks malicious domains), newer privacy-focused DNS providers (including Google, Cloudflare, and Quad9) have eschewed DNSCrypt and opted for the other, IETF-blessed contenders: DNS over TLS and DNS over HTTPS. DNSCrypt Proxy now supports DNS over HTTPS, and it includes Cloudflare, Google, and Quad9 in its configuration defaults.

TLS was once CloudFlare's focus when it came to strengthening encryption for Web traffic against snooping.

Hashing it out with TLS
DNS over TLS (Transport Layer Security) has a few advantages over DNSCrypt. For one, it's a proposed IETF standard. It's also pretty straightforward in its approach—it takes standard-format DNS requests and encapsulates them in encrypted TCP traffic. Aside from the TLS-based encryption, it's essentially the same as running DNS over TCP/IP instead of UDP.
There are few functioning clients for DNS over TLS. The best option I found, called Stubby, was developed by the DNS Privacy Project. Stubby is available as part of a Linux package, but there's also a MacOS version (installable with the Homebrew tool) and a Windows version—though the Windows code is still a work in progress.
While I got Stubby working reliably after wrestling with some code-dependency problems on Debian, it failed regularly on Windows 10 and has a tendency to hang on MacOS. If you're looking for a good how-to on installing Stubby on Linux, the best documentation I found was a Reddit post by Frank Santoso, who also wrote a shell script that can handle the task of installation on a Raspberry Pi.

On the upside, Stubby does allow for configurations that use multiple services based on DNS over TLS. Stubby's configuration file, written in YAML, allows for multiple IPv4 and IPv6 services to be set up, and it includes settings for SURFNet, Quad9, and other services. The YAML implementation used by Stubby is spacing-sensitive, however, so use caution when adding a new service (such as Cloudflare). I used a tab in my first attempt, and it blew the whole thing up.

DNS-over-TLS clients authenticate the service they connect to using Simple Public Key Infrastructure (SPKI). SPKI uses a locally stored cryptographic hash of the provider's certificate, usually based on the SHA256 algorithm. In Stubby, that hash is stored as part of the YAML description of the server in the configuration file, as shown below:

upstream_recursive_servers:
#IPv4
#Cloudflare DNS over TLS server

• address_data: 1.1.1.1
  tls_auth_name: "cloudflare-dns.com"
  tls_pubkey_pinset:
  • digest: "sha256"
    value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
• address_data: 1.0.0.1
  tls_auth_name: "cloudflare-dns.com"
  tls_pubkey_pinset:
  • digest: "sha256"
    value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

After the client establishes a TCP connection to the server over port 853, the server presents its certificate and the client checks it against the hash. If everything is fine, then the client and server do a TLS handshake, passing keys and starting an encrypted session. From there on, the data within the encrypted session follows the same rules as DNS over TCP.

After getting Stubby up and running, I changed my network settings for DNS to make requests to 127.0.0.1 (localhost). The change at the moment of the switchover, captured by the Wireshark packet capture tool, tells the story: my DNS traffic went from being readable to invisible

While DNS over TLS may function just like DNS over TCP, the TLS encryption takes a little bit of a toll on its performance. "Dig" queries to Cloudflare via Stubby took an average of about 50 milliseconds for me (your mileage may vary) as opposed to the sub-20-millisecond responses I got from naked DNS requests to Cloudflare.

Part of the performance problem is on the server side because of the added weight of using TCP. DNS typically uses UDP because of its connectionless nature—a UDP message is fire-and-forget, while a TCP message requires the negotiation of the connection and verification of receipt. A UDP-based version of DNS over TLS—called DNS over Datagram Transport Layer Security (DTLS)—is in its experimental phase and could increase the protocol's performance.

There's also a certificate-management issue here. If a provider retires a certificate and starts using a new one, there's currently no clean way to update the SPKI data on clients other than cutting and pasting it into the configuration file. Before this approach becomes fully baked, some sort of key-management scheme would be helpful. And since it operates on port 853—a port that isn't frequently opened up firewalls—DNS over TLS gets voted "most likely to be blocked."

That's not a problem for the last stop on our protocol hit parade, though: DNS over HTTPS passes through most firewalls like they aren't even there.

Google and Cloudflare seems to be on the same page with the future of encrypted DNS
DNS over HTTPS: DoH!
Google and Cloudflare both appear to favor DNS over HTTPS, also known as DoH, as the future of encrypted DNS. A draft IETF standard, the DoH protocol encapsulates DNS requests with secure HTTP—turning DNS requests into encrypted Web traffic.

Requests are sent as an HTTP POST or GET with queries in DNS message format (the datagram used in conventional DNS requests) or as an HTTP GET request using JSON (if you like your DNS with extra overhead). And there's no issue here with certificate management. Just as with normal HTTPS Web traffic, no authentication is required to connect over DoH, and certificate validity can be verified by a certificate authority.

A capture of a DNS transaction over DoH. HTTPS, TLS. That's all there is; there isn't any more

HTTPS is a pretty chunky protocol to be sending DNS requests with—especially with JSON along for the ride—so there's a little bit of a performance hit. The server-side resources required would almost certainly make a conventional DNS server admin's eyes water. But the ease of working with well-understood Web protocols makes developing both client and server code for DoH a lot more approachable to developers who've cut their teeth on Web applications. (Engineers at Facebook coded a proof-of-concept DoH server and client in Python in just a few weeks earlier this year.)

As a result, even though the pixels are barely rezzed on the RFC for DoH, there's already a raft of ready-to-run DNS-over-HTTPS clients, though some of them are built specifically for one DNS provider. The size of the performance hit your DNS resolution will take depends a lot on the server you point at and how well those developers did their job.

Take Cloudflare's Argo tunneling client (aka "cloudflared"), for example. Argo is a multipurpose tunneling tool intended primarily to provide a secure channel for Web servers to connect to Cloudflare's content delivery network. DNS over HTTPS is just another service that got bolted on.

By default, if you start Argo from the command line (which, in Linux and MacOS requires superuser privileges, and on Windows requires execution from Powershell as an administrator), Argo directs DNS requests to https://cloudflare-dns.com/dns-query. That causes a small problem if there's no conventional DNS server configured—if it can't resolve that address to 1.1.1.1, then it will fail to start.

This can be fixed in one of three ways. The first option is to configure your device with the local host (127.0.0.1 for IPv4 and ::1 in IPv6) as the primary DNS server for your network configuration and then add 1.1.1.1 as a secondary resolver. This will work, but it's not ideal for privacy or performance. A better option is adding the server's URL at the command line at startup:

$ sudo cloudflared proxy-dns --upstream https://1.0.0.1/dns-query

If you're convinced you want to make Cloudflare your way to roll—which gives you the benefit of automatic updates—you can set it up as a service in Linux, using a YAML-based configuration file that contains the IPv4 and IPv6 addresses of Cloudflare's DNS service:

proxy-dns: true
proxy-dns-upstream:

• https://1.1.1.1/dns-query
• https://1.0.0.1/dns-query

When configured with the proper upstream addressing, Argo's dig-query performance varied widely—from 12 milliseconds (for popular domains) to as much as 131 milliseconds. Pages with a lot of cross-site content took... a little longer than usual to load. Again, your mileage may vary, and it probably will be based on your location and peerage. But this is about what I expected from the lugubrious DoH protocol.

Like Cloudflare, we opted for tunnels rather than Affleck to illustrate Argo.

To confirm this was, in fact, a DoH issue and not a Cloudflare issue, I tried two other DoH "stubs." The first was a Go-based proxy for Google's DNS over HTTPS service called Dingo, a tool written by Paweł Foremski, an Internet researcher at the Institute of Theoretical and Applied Informatics of the Polish Academy of Sciences. Dingo works exclusively with Google's DoH implementation, but it can be tuned to use the nearest instantiation of Google's DNS service. That's a good thing—before tuning, the Dingo ate my DNS performance. Queries with dig averaged well over 100 milliseconds.

By checking how dns.google.com resolved from a standard DNS request, I got an alternate address to Google's default 8.8.8.8 IP address (172.217.8.14, if you must know). I appended that IP address to Dingo on the command line:

$ sudo ./dingo-linux-amd64 -port=53 -gdns:server=172.216.8.14
This cut response times down by about 20 percent—in the same ballpark, average-wise, as Cloudflare's Argo.

The best DoH performance, however, came from an unexpected source: DNSCrypt Proxy 2. With the recent addition of Cloudflare's DoH service to the stub's curated list of public DNS services, DNSCrypt Proxy will almost always connect to Cloudflare by default because of the server's low latency. To make sure, I even manually configured it for Cloudflare's resolver over DoH before throwing my battery of dig queries at it.

All of the queries were resolved in less than 45 milliseconds—faster than Cloudflare's own service by a wide margin. Using Google's DoH service, performance slowed a bit—queries averaged around 80 milliseconds. That speed came without tuning it to a more local Google DNS server.

On the whole, DNSCrypt Proxy's DoH performance was virtually indistinguishable from that of the DNS-over-TLS resolver I tested. In fact, it was faster. I'm not sure if this was because of how DNSCrypt Proxy implemented DoH—using the standard DNS message format encapsulated in HTTPS instead of the JSON format—or if it was related to how Cloudflare handled the two different protocols.

We are not Batman. But my threat model is still a bit more complicated than most.

Was this trip really necessary?

I am a professional paranoiac. My threat model is different from yours, and I would prefer to keep as much of my online activity as secure as possible. But given the number of current privacy and security threats that leverage manipulation of DNS traffic, there's a strong case for many people to use some form of DNS encryption. As I pleasantly discovered, there are implementations of all three of the protocols I looked at that don't have a profound negative impact on network traffic speeds.
However, it's also important to note that these services alone do not ensure your browsing is concealed. The Server Name Indicator (SNI) extension of TLS, used in HTTPS connections, can still reveal in plain text the name of the site you're visiting if the server it is on hosts multiple sites. For total privacy, you'll still need to use a VPN (or Tor) to encapsulate your traffic in a way that your ISP or some other party monitoring your traffic can't scrape metadata from (and none of these services work with Tor). And if you're dealing with a state-funded adversary, all bets are off.

The other problem is that while the fine folks in the DNSCrypt community have done great work, this kind of privacy is still too hard for average people. While I found it relatively easy to configure some of these encrypted DNS clients, none of them is exactly easy for normal Internet users to implement.For these services to become really useful, they have to be better integrated into the the stuff people buy—home routers and desktop and mobile operating systems.
Conventional DNS traffic is going to be increasingly monetized by Internet providers, and it will remain a tool of both states and criminals to steer Internet users into harm's way. But it's unlikely that major operating-system developers are going to embrace armoring up DNS in a way that's accessible to most users, because they're often in the same monetization game as ISPs. On top of that, those developers could face resistance to making changes from some governments that want to preserve DNS-monitoring capabilities.

So for now, these protocols are going to remain the tool of the few who care enough about privacy to go the extra mile. Here's hoping that the privacy community around DNSCrypt continues to care enough to push things forward.

dingo
A DNS client (stub resolver) implemented in Go for the Google DNS-over-HTTPS. It effectively encrypts all your DNS traffic. It also supports OpenResolve by OpenDNS.

The ultimate goal for the project is to provide a secure, caching DNS client that communicates with recursive DNS resolvers over encrypted channels only. For now, it resolves DNS queries over HTTP/2 in independent threads. The plans for future include better caching and support for QUIC.

Quick start
Download a pre-built binary for your platform from the latest release (or build your own binaries).

Run dingo as root on port 53. For example, on Linux:

$ sudo ./dingo-linux-amd64 -port=53
Update your DNS configuration. On Linux, edit your /etc/resolv.conf as root (remember to make backup first), e.g.:

$ sudo sh -c "echo nameserver 127.0.0.1 > /etc/resolv.conf"
Tuning dingo
You will probably want to change the default Google DNS-over-HTTPS server IP address, using the -gdns:server option. First, resolve dns.google.com to IP address, which should give you the server closest to you:

$ host dns.google.com
dns.google.com has address 216.58.209.174
dns.google.com has IPv6 address 2a00:1450:401b:800::200e
Next, pass it to dingo. If you prefer IPv6, enclose the address in brackets, e.g.:

$ sudo ./dingo-linux-amd64 -port=53 -gdns:server=[2a00:1450:401b:800::200e]
To see all options, run dingo -h:

Usage of dingo-linux-amd64:
-bind string
IP address to bind to (default "127.0.0.1")
-dbg int
debugging level (default 2)
-gdns:auto
Google DNS: try to lookup the closest IPv4 server
-gdns:edns string
Google DNS: EDNS client subnet (set 0.0.0.0/0 to disable)
-gdns:host string
Google DNS: HTTP 'Host' header (real FQDN, encrypted in TLS) (default "dns.google.com")
-gdns:nopad
Google DNS: disable random padding
-gdns:server string
Google DNS: server address (default "216.58.195.78")
-gdns:sni string
Google DNS: SNI string to send (should match server certificate) (default "www.google.com")
-gdns:workers int
Google DNS: number of independent workers (default 10)
-h1
use HTTPS/1.1 transport
-odns:host string
OpenDNS: HTTP 'Host' header (real FQDN, encrypted in TLS) (default "api.openresolve.com")
-odns:server string
OpenDNS: web server address (default "67.215.70.81")
-odns:sni string
OpenDNS: TLS SNI string to send (unencrypted, must validate as server cert) (default "www.openresolve.com")
-odns:workers int
OpenDNS: number of independent workers
-port int
listen on port number (default 32000)

Finally, you will need to make dingo start in background each time you boot your machine. In Linux, you might want to use the GNU Screen, which can start processes in background. For example, you might want to add the following line to your /etc/rc.local:

screen -dmS dingo /path/to/bin/dingo -port=53 -gdns:server=[2a00:1450:401b:800::200e]