AdGuard DNS-over-QUIC

AdGuard DNS is the first public DNS resolver to support the new DNS-over-QUIC protocol! We believe that DNS-over-QUIC (or simply DoQ) is the future of DNS encryption and we're extremely proud be the first to present you with the opportunity to try it out.

I'll kick off this article by explaining what DoQ is, then I'll cover its advantages compared to the alternatives, talk about whether there are any drawbacks or not, and finally give you a step-by-step instruction how to set it up.

Just in case you need to brush up on what DNS is and how it can be used to boost your online privacy, check out this article from almost exactly two years ago.

What is QUIC?

To be able to understand the intricacies of DNS-over-QUIC, it's only logical that first you should understand what QUIC is. So let's take one small step back to then make two steps forward. So, QUIC is a (relatively) new transport layer network protocol. "Ok, now he's just messing with me", you should be thinking. Simply speaking, QUIC serves as a protocol to transmit packets of data between servers or between a server and a client. There are other ways — other protocols — to do that, you probably at least heard of the good old TCP, which has been predominantly used on the web over the last years and even decades.

Compared to TCP, QUIC shows better speed, reliability, and provides better encryption. The fact that it was developed rather recently and not in the times of digital dinosaurs, means that it also solves several crucial problems that weren't obvious at all in the days of yore. I'll give a couple of examples why QUIC is superior to its predecessors.

Head-Of-Line Blocking

As mentioned, for the longest time we were at the mercy of TCP transport layer protocol and other protocols that we working over it — TLS, SSL, HTTP. I'm sure all these acronyms at least ring a bell, and that's because they've been around for ages, doing their job well. There's a catch, though: they've been doing it well under the near-perfect conditions of stable broadband connection. Step out of your house into the wilderness of 4G, LTE, and mobile data in general, and you'll inevitably run into such issues as weak signal, slow connection and whatnot. Even modern standards like 5G won't protect you from these nuisances — try riding an elevator, for example.

Years of acceptance made us view it as something natural — the network is bad, so pages load slowly or don't load at all. But why exactly? We approach the so-called "Head-of-line blocking" problem. With TCP, packets of data get transmitted in batches. Imagine your browser sends a bunch of requests, and the server replies with a bunch of responses, batched together in a specific order. One of them gets lost because of the weak connection and the house of cards crumbles. The rest of the responses can't get processed and have to wait in line for the lost packet to be resent, hoping that it gets through this time.

With TCP, if one data packet gets lost, the rest have to wait

Omitting the details, QUIC implementation allows data to get processed without any specific order. If the first data packet is lost due to a weak signal, the rest will be processed without delay nonetheless.

With QUIC, the other data packets can get processed even if the first one drops along the way

Connection Migration

We're used to the idea that every device on the Internet is uniquely defined by its IP address, and that's true, to an extent. But imagine a regular day of a normal person. Let's even take me for the sake of the example. Every workday morning I am leaving the comfort of my home (and its stable Wi-Fi) to go to work. As soon as my phone escapes the reaching area of the home router, my phone switches from Wi-Fi to 4G. Its IP address changes as well, and all active connections drop. I reopen the browser on the train to continue reading the article I started at home — the browser has to reestablish all those connections to the website and to my DoH server that runs on AdGuard Home. It takes time and I quickly run out of patience. Then I get to the office, connect to its Wi-Fi, and it's all the same story over again.

QUIC is designed with all this in mind. When QUIC is in use, your phone will survive switching from one IP address to another, an event that's called "Connection Migration", without any noticeable inconveniences for you as a user. Of course it's more complex, and QUIC allows connections to survive any changes to endpoint address, not just IP address (for example, port changes as well). You'll be easily able to find more information on the topic online if you want to.

DNS-over-QUIC

And now we get to the main dish. DNS-over-QUIC is a DNS protocol that takes advantage of the QUIC transport layer protocol and uses it to transmit DNS requests. Currently the DoQ standard is in the draft stage, but it doesn't prevent us from experimenting with it.

Why not DNS-over-HTTPS

It gets more complicated here: at one point DNS-over-HTTPS will also support QUIC, thanks to the future employment of HTTP/3 protocol that was built around QUIC. And this raises more questions: why do we need DoQ at all in this case?

There are, in fact, several reasons, but they all stem from the single fact that HTTP is not a transport layer protocol. It was designed for different reasons, and while it can serve as a substitute for a proper transport protocol, this would raise a lot of unnecessary risks. Specifically in privacy area, using HTTP to transfer DNS requests will lead to:

• HTTP cookies
• Other HTTP headers (Authentication, User-Agent, Accept-Language)
• More Fingerprinting opportunities for malefactors
• Tracking using ETag

While all these problems can be accounted for on the client side at the DoH level, the clients themselves vary greatly: browsers, operating systems, all kinds of other software. It's practically impossible to have a client-side solution for each and all of them.

AdGuard DNS-over-QUIC

We're proud to be the first among the public DNS resolvers to implement the current specification of DNS-over-QUIC into our DNS servers. And we offer you a chance to be among the first to try it! Currently the easiest way to do so is to use one of our mobile apps: AdGuard for Android or AdGuard for iOS.

Using DoQ in AdGuard for Android

• Open the app, then open the side menu
• Go to Settings > DNS Filtering and enable it
• Select any of AdGuard DNS servers from the list of available servers
• Under Server type choose DNS-over-QUIC (experimental)

Using DoQ in AdGuard for iOS

• Open the app, switch to the Protection tab
• Enable DNS protection and open its menu
• Under DNS server choose any of the available AdGuard DNS servers
• Select DNS-over-QUIC (experimental) from among the available protocols

Want more?

Then you shall receive more! Here's a compilation of links that will come useful if you want to double down on DoQ and also possess a little technical prowess:

• dnslookup — a basic utility to fire off DNS requests. Supports all popular modern protocols: DoH, DoT, DoQ, DNSCrypt.

• AdGuard Home — looking into setting up your own DoQ server? Easy-peasy! AdGuard Home received DoQ support in the latest update. If you run AdGuard Home as a public server, you can set up an encryption there.

• dnsproxy — for when AdGuard Home is a tad too complicated and you're in business for a simple forwarder. Use dnsproxy — a simple DNS proxy with DoH, DoT, DoQ and DNSCrypt support.

• DnsLibs — a C++ library that we use in our AdGuard products. Feel free to borrow it to incorporate DoQ into your own app.