Update AdGuard becomes the world's first public DNS-over-QUIC resolver!

Gandalf_The_Grey

Level 50
Verified
Trusted
Content Creator
Apr 24, 2016
3,919
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.

Omitting the details, QUIC realization 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.

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.
This and lot's more info can be found in this article at AdGuard Blog:
 

TairikuOkami

Level 31
Verified
Content Creator
May 13, 2017
2,046
Now that is something I am looking forward to, I would pick UDP over TCP for DNS requests any day.
I have recently allowed QUIC and youtube seems to load instantly, ads get skipped fine, unlike before.
Code:
browser://flags/#enable-quic
netsh advfirewall firewall add rule name="Yandex QUIC" dir=out action=allow protocol=UDP remoteport=80,443 program="Z:\Yandex\YandexBrowser\Application\browser.exe"
 

HarborFront

Level 59
Verified
Content Creator
Oct 9, 2016
4,823
Some info on QUIC here




The question is should one enables QUIC in the browser despite the slight performance it gains over privacy issue and does your firewall inspect QUIC traffic?

Quote from comment

The ‘QUIC’ protocol (Google originated BTW) appears to be insecure against webtracking by commercial as well as govt. trackers & surveillance. A user/browser may be (passively) uniquely tracked across a browsing session (and possibly across multiple sessions in some instances), without the need for cookies, other trackers, or fingerprinting, according to a recent University of Hamburg paper:

https://content.sciendo.com/downloadpdf/journals/popets/2019/3/article-p255.pdf

Thus, probably best not to enable this in your browser if you are privacy-minded, until this hole is patched … (I haven’t been able to find any mention that browser vendors have even addressed this to-date)

QUIC has already been enabled in Chrome for quite some time, surprise, surprise (Google builds in yet another hidden, powerful privacy-shredding tracker into its next-generation web technology and as well as its 60%-market-share-browser?? There’s a shocker for ya…)
You can disable this in most Chromium-based browsers, tho’, and/or otherwise at your OS firewall:

How to disable QUIC protocol in Google Chrome

Unquote
 
Last edited:

HarborFront

Level 59
Verified
Content Creator
Oct 9, 2016
4,823
One question on DNS.

Anyone knows how's the DNS priority sequence assuming all the DNS below are set?

1) VPN's DNS server
2) Windows DNS server settings
3) Browser's DNS server settings
4) DNS server settings in 3rd-party software like in Adguard
 
Last edited:

SeriousHoax

Level 37
Verified
Mar 16, 2019
2,659
One question on DNS.

Anyone knows how's the DNS priority sequence assuming all the DNS below are set?

1) VPN's DNS server
2) Windows DNS server settings
3) Browser's DNS server settings
4) DNS server settings in 3rd-party software like in Adguard
In Firefox where you can make it use DoH always by setting "network.trr.mode" to "3" in "about:config" overrides everything. Router DNS, Windows DNS, third party software DNS, VPN DNS. Everything.
 
Top