search

AdguardTeam / AdGuardHome

Network-wide ads & trackers blocking DNS server
https://adguard.com/adguard-home.html
GNU General Public License v3.0
24.67k stars 1.78k forks source link

DoQ connection to NextDNS doesn't work anymore #4644

Closed HellboyPI closed 2 years ago

HellboyPI commented 2 years ago

Issue Details

After updating AdGuard Home to latest stable version (v0.107.7) DoQ (DNS-over-QUIC) connection to NextDNS stopped working. In v0.107.7 AdGuard Home team added support for the final version of the DoQ standard.

NextDNS does not yet support this. They also use udp port 8853.

Is it possible to make a workaround until NextDNS team updates their DoQ implementation?

This problem is also mentioned on NextDNS forum: https://help.nextdns.io/t/83hddp1/is-quic-protocol-down

fernvenue commented 2 years ago

Maybe you can try to set the port in your config like this:

quic://example.dns:8853

And clearly they should support the final version of the DoQ standard.

HellboyPI commented 2 years ago

Maybe you can try to set the port in your config like this:

quic://example.dns:8853

I have already tried that. Unfortunately, it does not work.

ducnc1201 commented 2 years ago

Maybe you can try to set the port in your config like this:

quic://example.dns:8853

And clearly they should support the final version of the DoQ standard.

I tested NextDNS DoQ on port 853 and it still works, so it's not about the port. image

unknown4849 commented 2 years ago

so far quic adguard dns still work (maybe already support or configured?)

leo15dev commented 2 years ago

If you use dnslookup v. v1.7.0, it will not work.

dnslookup google.com quic://dns.nextdns.io
dnslookup v. v1.7.0
2022/06/08 16:10:14 Cannot make the DNS request: opening quic connection to quic://dns.nextdns.io:853: timeout: no recent network activity

dnslookup google.com quic://dns.nextdns.io:8853
dnslookup v. v1.7.0
2022/06/08 16:10:32 Cannot make the DNS request: reading response from quic://dns.nextdns.io:8853: EOF

dnslookup google.com quic://dns.nextdns.io:853
dnslookup v. v1.7.0
2022/06/08 16:10:47 Cannot make the DNS request: opening quic connection to quic://dns.nextdns.io:853: timeout: no recent network activity

dnslookup v. v1.6.0

dnslookup google.com quic://dns.nextdns.io
dnslookup v. v1.6.0
2022/06/08 16:19:23 Cannot make the DNS request: opening quic session to quic://dns.nextdns.io:853: timeout: no recent network activity

dnslookup google.com quic://dns.nextdns.io:8853
dnslookup v. v1.6.0
dnslookup result:
;; opcode: QUERY, status: NOERROR, id: 9733
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.    IN       A

;; ANSWER SECTION:
google.com.     297     IN      A       172.217.31.14

dnslookup google.com quic://dns.nextdns.io:853
dnslookup v. v1.6.0
2022/06/08 16:19:39 Cannot make the DNS request: opening quic session to quic://dns.nextdns.io:853: timeout: no recent network activity
HellboyPI commented 2 years ago

Tried also with: quic://dot-de.blahdns.com:784

It doesn't work. At the moment, with v0.107.7 of AdGuard Home only connections to AdGuard DoQ resolvers are possible.

ameshkov commented 2 years ago

RFC-version of DoQ is not compatible with the old draft versions, hence the issue.

AdGuard Home has already switched to the RFC-version of DoQ. AdGuard DNS supports both the old drafts and the RFC-version.

Unfortunately, this behavior is only normal for the server-side since it can distinguish the version the client wants to use. The client just uses the RFC-version and if the server is not compatible it won't get through.

Probably, the only way is to fix this on the NextDNS side. The fix is rather trivial, though. I'd suggest NextDNS to use the same approach as we do to support the old clients: https://github.com/AdguardTeam/dnsproxy/commit/c3b50a44f5b41cc0f385a0402e5dc127f08b0d1d#diff-6f8ef90801bf531405c62f0548dd80dc2edec8e10f96b0cd50c34544a7ea9c53R154

HellboyPI commented 2 years ago

@ameshkov Thank You for the help. I have sent Your answer to NextDNS. They responded: „The RFC specifies that DoQ enforces the same size limit for DNS messages, and it says that DoT and DNS over TCP are doing so via a 2 bytes size and DoH via the definition of the RFC. It does not say DoQ is using a 2 bytes message size.“

Maybe it would be best that AdGuard Home developers continue this conversation with NextDNS developers?

beerisgood commented 2 years ago

Maybe it would be best that AdGuard Home developers continue this conversation with NextDNS developers?

NextDNS team isn’t very active so you shouldn’t hope for a fast answer - if ever.

HellboyPI commented 2 years ago

They responded pretty fast in this case. They wrote, that they are planning to update their DoQ implementation very soon (next week). That being said, this thread can be closed. For now. 😃

ameshkov commented 2 years ago

@HellboyPI am I understanding that right that they've reviewed the RFC and admitted that there must be a prefix?

Just in case, here's the relevant part of the RFC:

All DNS messages (queries and responses) sent over DoQ connections MUST be encoded as a 2-octet length field followed by the message content as specified in [RFC1035].

HellboyPI commented 2 years ago

They wrote that there was a misunderstanding, but not anymore, and that they will update their servers.

leo15dev commented 2 years ago

They wrote that there was a misunderstanding, but not anymore, and that they will update their servers.

NextDNS had fixed this issue, now their DoQ can work in the AdGuard Home

dnslookup apple.com quic://dns.nextdns.io
dnslookup v. v1.7.0
dnslookup result:
;; opcode: QUERY, status: NOERROR, id: 0
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;apple.com.     IN       A

;; ANSWER SECTION:
apple.com.      348     IN      A       17.253.144.10