Anyone using DOH3 or DOQ for DNS-queries on ASUS Merlin?

[iJorgen]

I'm curious if anyone have setup DOH3 or DOQ successfully on an ASUS Merlin router for DNS-queries? So far I haven't seen any solution/add-on to do it on router-level. Any thoughts/plans on adding it native in the future like DoT is today or as an add-on in AMTM?

I read that some use the AdGuard app to get DOH3/DOQ on their devices, but would be so much better to have it on router-level for the whole network. It's a quite hot topic right now since Google recently released native support for DNS-over-HTTP/3 in Android

Some advantages picked from the article...

• As DoT operates on a single stream of requests and responses, many server implementations suffer from head-of-line blocking3. This means that if the request at the front of the line takes a while to resolve (possibly because a recursive resolution is necessary), responses for subsequent requests that would have otherwise been resolved quickly are blocked waiting on that first request. DoH3 by comparison runs each request over a separate logical stream, which means implementations will resolve requests out-of-order by default.
• Mobile devices change networks frequently as the user moves around. With DoT, these events require a full renegotiation of the connection. By contrast, the QUIC transport HTTP/3 is based on can resume a suspended connection in a single RTT.
• DoT intends for many queries to use the same connection to amortize the cost of TCP and TLS handshakes at the start. Unfortunately, in practice several factors (such as network disconnects or server TCP connection management) make these connections less long-lived than we might like. Once a connection is closed, establishing the connection again requires at least 1 RTT.
  In unreliable networks, DoH3 may even outperform traditional DNS. While unintuitive, this is because the flow control mechanisms in QUIC can alert either party that packets weren’t received. In traditional DNS, the timeout for a query needs to be based on expected time for the entire query, not just for the resolver to receive the packet.

PS. I know everyone has their strict opinion on DNS, but I hope we can have a friendly and open-minded discussion since it's a really good evolution for encrypted DNS with advantages compared to DoT. Would be a milestone, like when DoT was implemented.

 

[charlie2alpha]

Unknown if and when this will be implemented on the actual core firmware, those of us who are a little more advanced just install and use Adguard Home on our router running Merlin's firmware. Supports all of the secure DNS protocols both as server and as client.

 

[XIII]

I'm curious if anyone have setup DOH3 or DOQ successfully on an ASUS Merlin router for DNS-queries?

I use DOH via the NextDNS CLI, but don’t think I can use DOH3/DOQ yet?

 

[heysoundude]

I'm curious if anyone have setup DOH3 or DOQ successfully on an ASUS Merlin router for DNS-queries? So far I haven't seen any solution/add-on to do it on router-level. Any thoughts/plans on adding it native in the future like DoT is today or as an add-on in AMTM?

I read that some use the AdGuard app to get DOH3/DOQ on their devices, but would be so much better to have it on router-level for the whole network. It's a quite hot topic right now since Google recently released native support for DNS-over-HTTP/3 in Android

Some advantages picked from the article...


PS. I know everyone has their strict opinion on DNS, but I hope we can have a friendly and open-minded discussion since it's a really good evolution for encrypted DNS with advantages compared to DoT. Would be a milestone, like when DoT was implemented.

I'd love to see if there's a difference between encrypted and unencrypted rDNS, speedwise, and if there is a difference in speed between the protocols. maybe the unbound folks have some data on their website...

UPDATE: here's a link from unbound's nlnetlabs.nl website that may be insightful. (we are often discussing google vs cloudflare vs whomever DNS and there are SIGNIFICANTLY bigger deals - they're not even top-5!...wow)

DNSThought

I know that link doesn't answer the question, but it also doesn't mention much to do with it either... then again, I didn't dig into their published research too deeply...

UPDATE 2: there are some emails to people that may have better answers or know where to point you to get them at the end of this powerpoint:

https://nlnetlabs.nl/downloads/presentations/unbound_privacy_apricot2019.pdf

I think you had to be at the talk: the powerpoint seems to be simply a visual aid

 

[ColinTaylor]

Any thoughts/plans on adding it native in the future like DoT is today ...

DoT is a standard, unlike DoH and even more so DoH3/DoQ. Unless it becomes a standard (or very widely adopted) I don't see any urgent reason to add it to the base firmware (when it could be done as an addon or by the client). DoH3 uses QUIC which Google has been pushing for a number of years now but I'm not aware of anyone significant other than Google making use of it. Is there a list of servers that support DoH3, other than Google's (I presume)? I couldn't find one.

Correction: DoT is still showing as a proposed standard since May 2016. DoH became a proposed standard in October 2018.

 

[iJorgen]

I use DOH via the NextDNS CLI, but don’t think I can use DOH3/DOQ yet?

According to the NextDNS team, the CLI should support DOH3 right now, but I never got it to work. Tried disabling "client reporting" after a discussion in their forums since it needs DOH to transport the extra data, but couldn't get it to work. Only saw "DOH" what ever I tried.

Unknown if and when this will be implemented on the actual core firmware, those of us who are a little more advanced just install and use Adguard Home on our router running Merlin's firmware. Supports all of the secure DNS protocols both as server and as client.

Sounds tempting to try the AdGuard home package, but best for me would be a lightweight DOH3-client since I already use NextDNS for lists/filters. Similar setup like DoT that use Dnsmasq and Stubby.

DoT is a standard, unlike DoH and even more so DoH3/DoQ. Unless it becomes a standard (or very widely adopted) I don't see any urgent reason to add it to the base firmware (when it could be done as an addon or by the client). DoH3 uses QUIC which Google has been pushing for a number of years now but I'm not aware of anyone significant other than Google making use of it. Is there a list of servers that support DoH3, other than Google's (I presume)? I couldn't find one.

I read that the giants Google and Cloudflare have support, but some other providers (like NextDNS) should also have it enabled. Isn't DOH3 a standard now or was it QUIC that recently left the "draft" stage?!

 

[ColinTaylor]

I read that the giants Google and Cloudflare have support, but some other providers (like NextDNS) should also have it enabled.

We'd really need to know what server addresses (and ports) support it.

Isn't DOH3 a standard now or was it QUIC that recently left the "draft" stage?!

I don't know about DOH3 but QUIC went from being at the draft stage for over five years to a proposed standard standard just a few months ago.

RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport

This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and...

datatracker.ietf.org

Correction to my previous post: DoT is still showing as a proposed standard since May 2016. DoH became a proposed standard in October 2018.

 

[iJorgen]

We'd really need to know what server addresses (and ports) support it.

It sure is an interesting move from Google and will push the DNS evolution forward. Will follow how it goes even though I don't use Android.

Unknown if and when this will be implemented on the actual core firmware, those of us who are a little more advanced just install and use Adguard Home on our router running Merlin's firmware. Supports all of the secure DNS protocols both as server and as client.

Is it overkill (or even possible) to install the whole AdGuard Home package and then only use it to get DoQ/DOH3 against NextDNS servers?

 

[sfx2000]

I can't support DOH/DOH3/DOQ, as this adds complexity in an area where simplicity is key to security and performance.

(let's add a HTTPS stack to your DNS resolver, sure...)

DoT is good enough..

 

[Tech9]

For now I block both DoH (known DoH servers) and QUIC (80/443 UDP) on my network.

 

[N/A]

I can't support DOH/DOH3/DOQ, as this adds complexity in an area where simplicity is key to security and performance.

(let's add a HTTPS stack to your DNS resolver, sure...)

DoT is good enough..

When it's DoT vs DoH, I prefer DoT given the simplicity without HTTPS but DoH does have some advantages. Performance is better with HTTP/2 as stated in RFC 8484

"The messages in classic UDP-based DNS [RFC1035] are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to achieve similar performance. Those features were introduced to HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of conveying the semantic requirements of DoH but may result in very poor performance."

DoT with optional TCP keep alive can reduce the performance gap but server/client support isn't very common AFAIK.
Also DoH can blend inside regular HTTPS traffic which is good for privacy.

With DoQ, you have the advantages of DoH with even better performance since QUIC is UDP based like normal DNS. If you are really worried about HTTP/QUIC's security then nothing is safe since after getting DNS query through DoT, you're still going to initiate HTTP connections for whatever application you used.

 

[iJorgen]

With DoQ, you have the advantages of DoH with even better performance since QUIC is UDP based like normal DNS.

That's what sounds tempting to get even better performance with smarter packet loss/queue handling.

I decided to do a small "Proof of concept" to see how far I could get setting up a DoQ-proxy running on my router and it went surprisingly good. I'm now up and running "DNS-over-QUIC" against NextDNS for my whole network. Still some issues to solve, but was quite fun to see it was technically possible and first time using QUIC.

    "status": "ok",
    "protocol": "DOQ",
    "profile": "xxxx",
    "client": "xx.xx.xx.xx",
    "srcIP": "xx.xx.xx.xx",
    "destIP": "188.172.192.71",
    "anycast": false,
    "server": "anexia-cph-1",
    "clientName": "unknown-doq",
    "deviceName": "WAN",
    "deviceID": "xxxxx"

 

[Tech9]

What better performance we are talking about for a home/small network?

I block DoH simply because I don't see it and I have no control over it.

 

[XIII]

I decided to do a small "Proof of concept" to see how far I could get setting up a DoQ-proxy running on my router and it went surprisingly good. I'm now up and running "DNS-over-QUIC" against NextDNS for my whole network. Still some issues to solve, but was quite fun to see it was technically possible and first time using QUIC.

How?

 

[iJorgen]

How?

I found that the AdGuard Team had a DNS-proxy on Github supporting DoH/DoT/DoQ etc. Couldn't resist trying it out since I don't need the full AdGuard Home solution but just a DNS-proxy, so this was interesting. Try at own risk and not in production. I think these are all the steps I did:

1. Downloaded the latest build for linux/arm64: dnsproxy-linux-arm64-v0.43.1.tar.gz
2. Created a new directory under /jffs/scripts/dnsproxy and uploaded the executable from the archive to here. It's quite big (~8 MB), so watch out if you are low on JFFS-space.
3. Changed to allow executing:

   chmod +x /jffs/scripts/dnsproxy/dnsproxy

4. Disabled DNS-handling in DNSmasq by setting listeningport to 0

   -p, --port=<port>  Setting this to zero completely disables DNS function, leaving only DHCP and/or TFTP.

   nano /jffs/scripts/dnsmasq.postconf and add:

   pc_append "port=0" "/etc/dnsmasq.conf"

   Restart the DNSmasq service.
5. You can't have DoT activated on the router since Stubby will interfere with the listening-ports, so disable that too.
6. Now you can run it from command-line

   ./dnsproxy -l 127.0.0.1 -l 192.168.1.1 -p 53 -b 1.1.1.1:53 -u quic://WAN-<configid>.dns.nextdns.io

You can also have a separate config-file with all settings and point to it instead:

./dnsproxy --config-path=/jffs/scripts/dnsproxy/dnsproxy.yaml

Known issues:

• Can't reach local resources in the LAN, so guess it's some setting (rebind-protection?!). Haven't tested deeper if any other functions are broken after disabling DNS in DNSmasq.
• Not sure how to run it automatically the best way, since it's just command-line now that gets "stuck" and not running as a daemon. Any tips?!

Like I wrote, I did this just as a rough 2 hour POC to see if I actually could get DoQ to work, so there are still things to fix. Have switched back to DoT, but would be fun to improve it as a side-project and making it fully functional. Any feedback/tips for improvement and doing things a better way are very welcome!!

Maybe this "AdGuard Proxy" could be packaged like "AdGuard Home" is today in AMTM with an installer/configurator as a light-weight alternative to the full AGH-package. That's above my knowledge, but there are many smart people here

 

[sfx2000]

When it's DoT vs DoH, I prefer DoT given the simplicity without HTTPS but DoH does have some advantages. Performance is better with HTTP/2 as stated in RFC 8484

(snip)

DoT with optional TCP keep alive can reduce the performance gap but server/client support isn't very common AFAIK.
Also DoH can blend inside regular HTTPS traffic which is good for privacy.

With DoQ, you have the advantages of DoH with even better performance since QUIC is UDP based like normal DNS. If you are really worried about HTTP/QUIC's security then nothing is safe since after getting DNS query through DoT, you're still going to initiate HTTP connections for whatever application you used.

I personally don't buy the explanation that the RFC editors are promising...

Again, adding an HTTPS stack to a DNS resolver isn't the greatest idea - additional complexity on all end points, from the client to the resolver upstream, and a larger threat surface.

Adding QUIC just compounds the problem.

That being said, if people want to do it, that's ok by me...

 

[XIII]

I think these are all the steps I did

Do you use the NextDNS CLI on your router?

(I do and I don't think the steps will work in combination with that?)

This setup reports DOH:

    "protocol": "DOH",

 

[iJorgen]

Do you use the NextDNS CLI on your router?

No, the CLI is a whole other solution doing DOH and won't work with this POC.

Both DoQ and DOH3 are still in it's early days, but it's interesting to see Google taking a big step now integrating it into Android.
Good evolution for the old DNS-protocol that was built in the 1980's without any security in thought back then.

 

[SomeWhereOverTheRainBow]

I'm curious if anyone have setup DOH3 or DOQ successfully on an ASUS Merlin router for DNS-queries? So far I haven't seen any solution/add-on to do it on router-level. Any thoughts/plans on adding it native in the future like DoT is today or as an add-on in AMTM?

I read that some use the AdGuard app to get DOH3/DOQ on their devices, but would be so much better to have it on router-level for the whole network. It's a quite hot topic right now since Google recently released native support for DNS-over-HTTP/3 in Android

Some advantages picked from the article...


PS. I know everyone has their strict opinion on DNS, but I hope we can have a friendly and open-minded discussion since it's a really good evolution for encrypted DNS with advantages compared to DoT. Would be a milestone, like when DoT was implemented.

You can already use this with AdGuardHome addon, and soon dnscrypt-proxy. Dnscrypt-proxy devs are already adding in http/3 support for DOH3.

Add suport for DoH over HTTP/3 · DNSCrypt/dnscrypt-proxy@5977de6

dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols. - Add suport for DoH over HTTP/3 · DNSCrypt/dnscrypt-proxy@5977de6

github.com

The real part I have never fully gotten on board with is the whole "I can't trust my ISP for DNS, but somehow I trust sending my encrypted request to the BIG neighbor DNS provider." Other than skipping out on some geographical or ISP imposed restrictions, what is the real benefit here when in most counties the same DNS providers are able to share consumer information the same way the internet service providers themselves are.

 

[iJorgen]

You can already use this with AdGuardHome addon, and soon dnscrypt-proxy. Dnscrypt-proxy devs are already adding in http/3 support for DOH3.

Thanks for your answer, @SomeWhereOverTheRainBow. I'm trying keep my setup as minimal/efficient as possible so was hoping to not install the whole AdGuardHome suite with USB-stick, swap and Entware since I use all it's features in NextDNS. Just a DNSproxy to evaluate DoQ/DoH3. Interesting that DOH3 is also coming to DNSproxy soon as you mention. Much happening around DNS now...

The real part I have never fully gotten on board with is the whole "I can't trust my ISP for DNS, but somehow I trust sending my encrypted request to the BIG neighbor DNS provider."

I have no trust issues with my ISP and don't even use VPN. What I am striving for is to always optimize my setup and I love to evaluate new technologies. I have now managed to get DNSproxy to run quite well together with DNSmasq, when I watched how DoT was configured using Stubby listening on 127.0.1.1 and did a similar setup.

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      31543/dnsmasq
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      31543/dnsmasq
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      31325/dnsproxy
udp        0      0 127.0.0.1:53            0.0.0.0:*                           31543/dnsmasq
udp        0      0 192.168.1.1:53          0.0.0.0:*                           31543/dnsmasq
udp        0      0 127.0.1.1:53            0.0.0.0:*                           31325/dnsproxy