Don't forward queries that can't be answered by public DNS servers

[emlimap]

(@ainar-g: updating the top post to summarize the discussion, define the UI, and add the special-use domains; original content is under the <details> tag.)

Currently, AdGuard Home forwards all queries upstream, even ones that can't be answered by public DNS servers like PTR record lookup for private-use IP addresses or for domains like localhost, home.arpa, and lan, to name a few. This presents two issues, one is the added latency of receiving NXDOMAIN response for something public DNS can't answer and the other is leaking queries to a third-party service.

AdGuard Home shouldn't forward queries that can't be answered by upstream DNS servers by default unless there is a manual forward definition defined in Upstream DNS servers section.

Proposed changes:

• UI:

  • Add a new section to the Settings → DNS settings page (probably right before the Access settings section) with the following checkboxes:

    • Enabled (to enable or disable this feature entirely);
    • Block Special-Use Domain Names (like *.example etc.);
    • Block Undelegated Domain Names (like modem, local, etc.);
    • Block Unqualified Domain Names (domains that consist of only the top-level domain).

• Internals:

  • See the original post content for great tips on implementation.
  • The unqualified and special-use checks are relatively easy to implement without the need for urlfilter-like rules. The undelegated domains check might require them.
  • The special-use check must work in accordance with RFC 6761.

• Configuration file:

  • The new object is added to object dns:

    block_special:
        enabled: true
        special_use: true
        undelegated: true
        unqualified: true

    (These are the default values.)

---

Original post content

### Problem Description At the moment AGH forwards all queries upstream, even ones that can't be answered by public DNS servers like PTR record lookup for private IP addresses or for domains like `localhost`, `home.arpa`, `lan` to name a few. This presents two issues, one is the added latency of receiving NXDOMAIN response for something public DNS can't answer and the other is leaking queries to a 3rd party service. ### Proposed Solution Adguard shouldn't forward queries that can't be answered by upstream DNS servers by default unless there is a manual forward definition defined in Upstream DNS servers section. I am not sure what is the best method of implementation for this, so I will just point out some implementation examples from other projects. dnscrypt-proxy comes with following optioned enabled by default. ```toml ## Immediately respond to A and AAAA queries for host names without a domain name block_unqualified = true ## Immediately respond to queries for local zones instead of leaking them to ## upstream resolvers (always causing errors or timeouts). block_undelegated = true ``` Source: https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml For blocking unqualified domains, this seems to be the plugin that handles it - https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/plugin_block_unqualified.go And the plugin for undelegated domains and PTR records - https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/plugin_block_undelegated.go Some of those PTR records are from https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml DNSMasq has the following option. ``` -f, --filterwin2k Later versions of windows make periodic DNS requests which don't get sensible answers from the public DNS and can cause problems by triggering dial-on-demand links. This flag turns on an option to filter such requests. The requests blocked are for records of types SOA and SRV, and type ANY where the requested name has underscores, to catch LDAP requests. ``` Openwrt uses the above option along with filtering private IP address in the dnsmasq that they ship - https://github.com/openwrt/luci/blob/aac1a8d512643e3864843d2c2b3c6ee7f7f2a3d2/modules/luci-mod-network/htdocs/luci-static/resources/view/network/dhcp.js#L212-L219 ### Alternatives Considered Write rules to block queries that can't be answered upstream with exceptions for internal domains & PTR for internal IP range which are forwarded to router's DNS server. ### Additional Information While undelegated domains & PTR records can be handled by creating rules to block requests with some exceptions to ones you use, it would be good have this feature built into AGH and enabled by default so it benefits all users not just the ones who can write their own rules.

[DandelionSprout]

Looking up PTR requests on my own AGH server, I noticed that ≥80% of them were in the formats of 64.1.168.192.in-addr.arpa and b._dns-sd._udp.64.1.168.192.in-addr.arpa, which indeed doesn't seem like something that upstream DNS servers should have to deal with.

[ameshkov]

It actually is.

This is AdGuard Home trying to automatically resolve hostname of the clients.

[ameshkov]

Moved here: https://github.com/AdguardTeam/AdGuardHome/issues/2704

[ameshkov]

Ah, on the other hand, this is not actually a duplicate. Reopened.

[gyCfjSnO]

Any update on blocking local DNS queries? I made a dirty fix by making a block rule in custom filtering that matches my networks local domain name.

[vordenken]

A solution for this would be awesome! A lot of traffic generated here which is totally unnecessary in my opinion.

[adrianmace]

@ameshkov the current behaviour actually breaks the RFC related to home.arpa. I think. Specifically Section 4.4.B.

With a recent update to Apple devices, they are now frequently making unicast DNS requests to device-name.openthread.thread.home.arpa.

It would be great to be able to blanket block these through a similar global option to what DNScrypt appears to offer.

[ameshkov]

That makes sense, thank you!

@ainar-g can we schedule this?

@adrianmace meanwhile, the temporary solution would be to use $dnsrewrite rules to do this: *.arpa^$dnsrewrite=NXDOMAIN

[adrianmace]

Thanks that worked perfectly.

I will note that it's worth doing this for *home.arpa specifically, rather than the entire *.arpa namespace.

[funny-fury]

Maybe refer to the IANA documentation Special-Use Domain Names, which by default prevent these domains from being forwarded to public dns resolvers. If these domains are specified to be forwarded upstream, they will be forwarded to specific dns resolvers according to the settings.

[cookiengineer]

I wanted to add that this problem still persists.

I'm using AdGuard Home on OpenWRT, and a lot of unresolvable domains are forwarded to the public DNS resolver:

AirPrint examples from an iOS device:

• lb._dns-sd._udp.lan (see dns-sd.org, it's multicast DNS handshake)
• lb._dns-sd._udp.0.1.168.192.in-addr.arpa (PTR which is the reverse lookup)

Some fallback domain lookups from Firefox when connection troubles are detected:

• detectportal.firefox.com.lan
• shavar.services.mozilla.com.lan
• push.services.mozilla.com.lan