Configurable SVCB _dns.resolver.arpa record to allow DNR for custom DoH

Feature Requests
1

This feature request improves on the GitHub Pull Request #2315 which is blocking SVCB _dns.resolver.arpa and returning NODATA by default now to prevent clients from upgrading to public DoH from Pi-hole. (See the feature request: Implement _dns.resolver.arpa as a special domain or add BLOCK_SVCB as a configuration option)

I would like to request a feature to have an option from the configuration files of Pi-hole to customize the SVCB _dns.resolver.arpa record to allow setting custom local DoH server available for upgrade from the plaintext DNS using Discovery of Network-designated Resolvers (DNR). (As of now Pi-hole allows setting custom A/AAAA/CNAME records from web interface under Settings -> Local DNS Settings.)

You might be wondering if allowing SVCB to specify a custom DoH server would defeat the purpose of using Pi-hole. However, it is possible to provide a DoH server that uses Pi-hole as its upstream resolver.

How Discovery of Network-designated Resolvers (DNR) works:

  1. A client gets a DNS resolver IP via DHCP Option 6 (IPv4) or Option 23 (IPv6) [Which will be the Pi-hole IP]
  2. The client performs a reverse DNS lookup on _dns.resolver.arpa and SVCB record tell the client where the DoH/DoT endpoints are.
  3. If valid records exist, the client automatically upgrades to encrypted DNS.
2

Hi, author of the feature request here.

If you've a downstream DNS server that supports DoH/DoT, why not direct all clients to use that DNS server and upgrade through that?

The reality is that the benefits for DoH/DoT in a home LAN are almost non-existent, while DoH upgrades over WAN are pervasive in almost all public resolvers. Enterprise LAN is another story, but you should be using other methods for upgrading there, such as dnsdist.

3

It seems that this request, generalised to the ability to have local SVCB (and HTTPS) records, would probably be better directed upstream to the dnsmasq mailing list, rather than implementing it only for _dns.resolver.arpa. It seems likely that it is a feature that would be implemented at some time in the future as more use is made of these new record types.

1 Like
4

My goal here was to keep using Pi-hole as filtering DNS, while enabling DoH/DoT on my network while Pi-hole is the upstream. I've used Unbound to accept encrypted traffic on 443/853 and forward to pi-hole. This only worked only when I've manually configured the browser to specify custom DoH. Customzing DNR should in theory allow supported client to upgrade to DoH to have "Secure DNS"

As the browser is refusing to connect with Encrypted Client Hello (ECH) when no Secure DNS is enabled (works well with public DoH, but I will not have pi-hole filters). See this topic DoH DNS and DNR in Front of Pi-hole

5

Thank you robgill, your documented steps in this topic are exactly what I wanted to achieve DNS delivery of Discovery of Network-designated Resolvers (DNR)