DNS-over-QUIC any1? ;)

[hwzlite]

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

> Setup AdGuard Home replacing your Pi-Hole

 

[uncle_josh]

What is QUIC?

The link provided never explain properly !!!

With QUIC this is not yet possible, since NAT routers deployed in the wild today do not understand QUIC yet, so they typically fallback to the default and less precise handling of UDP flows, which usually involves using arbitrary, and at times very short, timeouts, which could affect long-running connections

Source : The Road to QUIC

 

[bert64]

What is QUIC?

The link provided never explain properly !!!

With QUIC this is not yet possible, since NAT routers deployed in the wild today do not understand QUIC yet, so they typically fallback to the default and less precise handling of UDP flows, which usually involves using arbitrary, and at times very short, timeouts, which could affect long-running connections

Source : The Road to QUIC

It works with NAT, just not as well as it's supposed to. You can access the adguard servers over IPv6 and avoid NAT.

Standard DNS works over UDP, DNS over HTTPS adds extra latency because it has to complete the 3 way TCP handshake, negotiate SSL, and finally send the request and wait for a response.

TLS 1.3 is designed to reduce latency by streamlining the SSL negotiation, but a lot of places don't yet support TLS 1.3.

QUIC is designed to address the TCP latency, and reduce the SSL latency by using TLS 1.3.

The purpose of DNS over HTTPS or QUIC is so your ISP can't see what sites you are trying to access by snooping your DNS requests. Running your own resolver at home kind of defeats this purpose, as it will still be sending standard DNS requests upstream. Only the connection between the adguard server and your client will use QUIC/HTTPS.

TLS 1.2 and earlier can also leak some information, the hostname of the site is still leaked in clear text and can be viewed on the wire. TLS 1.3 addresses this too.

So TLS1.3, QUIC, DNS over QUIC, IPv6 - all superior replacements, but slow adoption because users don't understand the benefits.

 

[hwzlite]

The Internet Engineering Task Force (IETF) is in the midst of making it a worldwide standard. With mass adoption, will comes more hardware supporting it, especially to appease the security folks.

 

[bert64]

The Internet Engineering Task Force (IETF) is in the midst of making it a worldwide standard. With mass adoption, will comes more hardware supporting it, especially to appease the security folks.

TLS 1.3 has been an IETF standard for 2 years...
IPv6 has been an official IETF standard for 3 years, and has been around for more than 20.

 

[hwzlite]

Tips: So far so good running under local hosted.AdGuard Home.
Just simply input "quic://dns-unfiltered.adguard.com:784" as the only upstream server.

For cloud hosted , have to get through the hassle of configuring Encryption/SSL certificate :

 

[xiaofan]

Interesting the following article seems to advocate disable QUIC and DNS over HTTPS.
https://medium.com/cloud-security/quic-and-dns-over-https-6878dcbdfde3

 

[xiaofan]

Interesting the following article seems to advocate disable QUIC and DNS over HTTPS.
https://medium.com/cloud-security/quic-and-dns-over-https-6878dcbdfde3

The author also questions the following about IPv6. Indeed this is an interesting question.
"I always wonder about the decision to expose MAC addresses in IPv6 as some people (and even security products!) have been known to use these addresses to enforce security rules."

 

[hwzlite]

Interesting the following article seems to advocate disable QUIC and DNS over HTTPS.
https://medium.com/cloud-security/quic-and-dns-over-https-6878dcbdfde3

Check this out, FF to 13:48mins onwards

 

[xiaofan]

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

> Setup AdGuard Home replacing your Pi-Hole

BTW, I have tried both Pi-hole and Adguard Home on the Cloud (Free tier of Google Cloud and Oracle Cloud), in the end I feel Pi-Hole is easier to maintain and set up. My main problem was actually dealing with Let's Encrypt certificate with Adguard Home. I think it can be resolved with some more tries. The other thing is that it requires more memory than Pi-hole so it can be a problem with free tier of Google Cloud.

I set up firewall rules to limit Pi-hole DNS only for my public IP and also configure DNS over HTTPS using Cloudflared.
https://docs.pi-hole.net/guides/dns-over-https/

I read that there are some benefits of Adguard Home compared to Pi-Hole but then I am comfortable with Pi-hole now.

In reality, most of the "X" items in the following comparison from Adguard are not really true as you can use "additional software" and "non-default blocklists" anyway. And Pi-hole is anyway mainly for Linux and you can use Raspberry Pi or Docker or the Cloud to deploy Pi-hole.
https://kb.adguard.com/en/home/overview

 

[bert64]

The author also questions the following about IPv6. Indeed this is an interesting question.
"I always wonder about the decision to expose MAC addresses in IPv6 as some people (and even security products!) have been known to use these addresses to enforce security rules."

Some IPv6 implementations derive their local autoconfig address based on the MAC address, a method known as EUI-64. The purpose being that it's predictable, so if you move to a different network entirely or your isp assigns you a different address block, the host part of each device address is always the same.

It is however optional, neither windows nor macos use it by default, instead coming up with a random address, although it persists across reboots so seems to be created once and saved.

There is also the concept of privacy addresses... So you have a single static address that you can use if you want to allow inbound traffic to a particular host, and you have ephemeral random addresses which are used when making outbound connections so that anyone receiving these connections cannot track individual hosts - at least not at the network layer.

So under the default configuration a site receiving ipv6 connections from users will receive connections from the random ephemeral privacy addresses, and only be able to correlate users to the /64 block they originated from.
If you as the owner of the machine wish to connect back to it from elsewhere, you connect to the static address.

All of these features can be turned on or off as per your requirements. Sometimes predictable addresses are useful, for instance when deploying servers or other devices intended to be managed remotely etc.

 

[bert64]

Interesting the following article seems to advocate disable QUIC and DNS over HTTPS.
https://medium.com/cloud-security/quic-and-dns-over-https-6878dcbdfde3

From that article:

"I found that it hurt the ability for network security products to see, inspect, and block unwanted traffic."...

Well first if he wanted to control traffic flows, he shouldn't have been allowing unknown protocols in the first place therefore QUIC wouldn't have been used. Plus any encrypted protocol is going to prevent security products (and indeed anything else) from inspecting it because that's the whole point. If you are concerned about the contents of encrypted sessions, then you need to implement interception.

Second, this seems to be typical fear of the unknown... Boo hoo something new is coming along that i don't understand so i'm going to ignore or block it rather than learn how it might be beneficial. The same can be said of the mentioned security products, as commercial vendors tend to be extremely slow to support new tech - which in itself is a big problem because skilled hackers will be the first to embrace anything new.

QUIC as a protocol has clear performance benefits over HTTP.

DNS over en encrypted channel reduces performance but prevents those on your network path from seeing what you're looking up. But it does little good if after looking up the host you then connect to it over an unencrypted channel or using TLS <1.3 because anyone with access to the network can still see the hostname in the handshake.

 

[uncle_josh]

DNS over encrypted channel reduce performance but negligible lah.
See here : DNS-over-HTTPS performance

 

[hwzlite]

BTW, I have tried both Pi-hole and Adguard Home on the Cloud (Free tier of Google Cloud and Oracle Cloud), in the end I feel Pi-Hole is easier to maintain and set up. My main problem was actually dealing with Let's Encrypt certificate with Adguard Home. I think it can be resolved with some more tries. The other thing is that it requires more memory than Pi-hole so it can be a problem with free tier of Google Cloud.
https://kb.adguard.com/en/home/overview

Did you try https://certbot.eff.org for generating Let'sEncrypt cert?
My cert is registered under my free ddns.net domain, which is fairly easy to get it running on Adguard Home.

Generally, I would prefer running apps/services locally for speed+simplicity in my 24/7 all-in-1-rig rather than hosting in the cloud.

 

[xiaofan]

Did you try https://certbot.eff.org for generating Let'sEncrypt cert?
My cert is registered under my free ddns.net domain, which is fairly easy to get it running on Adguard Home.

Generally, I would prefer running apps/services locally for speed+simplicity in my 24/7 all-in-1-rig rather than hosting in the cloud.

Yes I use that and it works fine with Pi-Hole and my other installations of V2Ray/Trojan, using my free FreeNom domains (but using Cloudflare for DNS), but it did not work with Adguard Home. Anyway, I do not want to debug further as I feel Pi-hole is good enough for me.

I understand the benefits of using local services. However, it is actually pretty simple to deplopy over the cloud as well once I figured out the Firewall settings of Google/Oracle. So far I do not want to run a server 24/7 at home. I only use the router/AP 24/7. But that may change once I get my mini x86 PC which I intend to try out pfsense.

 

[hwzlite]

For ppl prefer video over text : A presentation on DNS-over-QUIC (DoQ) by Andrey Meshkov of AdGuard, FF to 5:40mins .

 

[hwzlite]

Cool, https://adhole.org now supports DNS over QUIC (DoQ) which can be added as upstream DNS server ( quic://sg.adhole.org:784 )