Support for DDR - (Discovery of Designated Resolvers)

[gspannu]

Feature Request - AGH to support Discovery of Designated Resolvers (DDR)

With all of the new methods for DNS encryption, clients need an automated means to discover what encryption methods their chosen DNS resolver supports.

The Adaptive DNS Discovery (ADD) working group at the IETF has proposed a standard called Discovery of Designated Resolvers (DDR).

The basics of DDR are simple. When a DNS client first finds out its DNS server, it will send a DNS query for a special use domain name, ‘_dns.resolver.arpa’, using a special DNS query type (type 64, or ‘SVCB’). The DNS server will respond with the different types of encryption it supports, and any configuration information the client needs.

The client can pick the kind of encryption it prefers, verify that all the information is secure, and then start encrypting DNS.

Any plans for AdGuard Home to support this in future builds?

[ameshkov]

We should definitely add support of DDR to AGH, this is a trivial change.

[gspannu]

You guys are awesome 👍

[ainar-g]

@gspannu, you can actually already use parts of the DDR spec draft in AdGuard Home today. Using the custom rule:

||_dns.example.net^$dnsrewrite=NOERROR;SVCB;1 . alpn=dot port=8530

You can already generate a response like that mentioned in the RFC:

env RRTYPE=SVCB dnslookup '_dns.example.net' "$MY_AGH_ADDR"

;; opcode: QUERY, status: NOERROR, id: 53606
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_dns.example.net.      IN       SVCB

;; ANSWER SECTION:
_dns.example.net.       10      IN      SVCB    1 . alpn="dot" port="8530"

The DoH part of the spec isn't properly supported yet, because our parser ignores the dohpath attribute, but we will fix that soon and merge that fix into one of the upcoming v0.107 patch releases.

We'll think about the best way to implement this out-of-the-box for AGH v0.108.0, since that probably will require a configuration change.

[gspannu]

I presume the final solution in v0.108 would fully support

• DoT, DoH, QUIC
• over encrypted resolver
• over unencrypted resolvers

In addition (as a feature request) are you looking to add a command option to your excellent program dnslookup the ability to decode and present DDR results in an easy to read verbose format?

[ainar-g]

@gspannu, the details of the implementation are to be determined later. For dnslookup, it's better to create a new issue in its repo, I think.

[agneevX]

I presume the final solution in v0.108 would fully support

From what I've read here (https://blogs.cisco.com/networking/improving-dns-security-while-preserving-resiliency), this appears to be a way for connecting clients to know whether they can connect via DoT or DoH instead of regular DNS to the same DNS server.

This does not affect how DNS server resolves queries.

[gspannu]

I presume the final solution in v0.108 would fully support

From what I've read here (https://blogs.cisco.com/networking/improving-dns-security-while-preserving-resiliency), this appears to be a way for connecting clients to know whether they can connect via DoT or DoH instead of regular DNS to the same DNS server.

This does not affect how DNS server resolves queries.

Apologies, if was not clear.

I meant that if a user had enabled DoT, DoH and QUIC in the encryption tab - then the AGH server should report back all 3 types - when any client requests for this information.

The other bit about dnslookup was a feature request to add a command line parameter like dnslookup -ddr "$MY_AGH_ADDR" and the result would be a verbose description of the result.

[agneevX]

Oh good, I misunderstood you then.

I haven't gone through the draft, but if it's supported, it can probably be done.

[EugeneOne1]

@gspannu, we've merged our DDR implementation in c4ff80f. It's already available in the latest edge builds. Could you please check if it works for you? Thanks.

[ainar-g]

We'll close this issue for now. Please feel free to report new issues with the feature on the beta channel.

[EugeneOne1]

It seems, the priority of returned SVCB records is constant for each supported protocol, so if the DoH server is down and DoT/DoQ is up, the priority numbers won't begin with 1. Not sure if it's critical, but at least not quite accurate.

[ainar-g]

@gspannu, just as an FYI, we have released this feature in v0.107.10.

[pratyushdikshit26]

I wanted to check the DDR support by the DNS resolver, such as 1.1.1.1
I tried with the following python code

import dns.resolver

resolver = dns.resolver.Resolver()
resolver.nameservers = ["1.1.1.1"] # set the DNS resolver to query

svc_query = "_dns.resolver.arpa"
response = resolver.resolve(svc_query, rdtype=dns.rdatatype.SVCB)

for rdata in response:
print(rdata) # print the SVCB record

This code shows the output as -
1 one.one.one.one. alpn="h2" port="443" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001" key7="/dns-query{?dns}"
2 one.one.one.one. alpn="dot" port="853" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001"

Just by seeing "h2" and "dot" support, can I conclude that the resolver 1.1.1.1 supports DDR?

[ameshkov]

Just by seeing "h2" and "dot" support, can I conclude that the resolver 1.1.1.1 supports DDR?

It does.

Note, that AGH supports DDR as a DNS server, not as a DNS client.
I've opened a feature request about client-side DDR support: AdguardTeam/dnsproxy#321

[pratyushdikshit26]

Thank you @ameshkov for your response.
Just in continuation to the previous question, is it sufficient to check the IP address of the DNS nameservers rather than the IP address of the specific resolvers to verify DDR support at the server level?

Just by seeing "h2" and "dot" support, can I conclude that the resolver 1.1.1.1 supports DDR?

It does.

Note, that AGH supports DDR as a DNS server, not as a DNS client. I've opened a feature request about client-side DDR support: AdguardTeam/dnsproxy#321