Improve the way PTR queries for local IP addresses are sent

[ameshkov]

Currently, we ask people to use this instruction in order to re-route local PTR queries to the proper DNS server. This is not an ideal solution and we can do this automatically.

Here's what we should do.

1. If AdGuard Home is a DHCP server, we shouldn't send PTR queries for local IP addresses anywhere, AGH already has enough information by itself.
2. If AdGuard Home is not a DHCP server, we should send those queries to the local resolver (which address we can obtain via DHCP ourselves). Additionally, we could allow configuring the local resolver address via AdGuardHome.yaml.
3. Note that AG Home is often configured to be the default resolver in /etc/resolv.conf. In light of this, we should make sure to not send those queries to AGH itself.

[dioey]

@ameshkov Hi I have MikroTik as DHCP server one for LAN and one for VLAN, for AdGuard Home get 2 IP Address from LAN and VLAN, 192.168.0.16 for LAN Interface, 10.5.50.16 for WiFi Interface, the problem is the WiFi Interface 10.5.50.16 always send PTR queries for local IP addresses both for LAN and WiFI subnet, if the second Instruction with[/168.192.in-addr.arpa/]192.168.0.1 and [/10.in-addr.arpa/]10.5.50.16 you said above is allow that queries, I tried that and change default resolver in /etc/resolv.conf how many i change that it always come back too # Generated by NetworkManager nameserver 10.5.50.16 is that the right step? for now I block PTR queries with REGEX, I need your advice for that. And please bare with me i am not familiar with Linux in general just tried anything that i can find in Google

[ghost]

Thanks for bringing all of these PTR related issues together, here are some more supplementary info that I think you might find useful:

• As #2702 stated, sometimes when AGH is running on a normal linux host (in a container) serving only the host itself, hostname resolution is essentially meaningless. Not only there is absolutely nothing that is able to answer that PTR lookup, when it gets up to the public resolver, it's also a privacy concern as this pretty much signals "this person is running AdGuardHome in a container". A checkbox to disable this feature entirely would be highly appreciated.

If AdGuard Home is not a DHCP server, we should send those queries to the local resolver (which address we can obtain via DHCP ourselves). Additionally, we could allow configuring the local resolver address via AdGuardHome.yaml.

• 1705 provides an excellent proposal detailing how other DNS solutions handles PTR. One more thing I'd like to note is that on such a network where AGH is not the DHCP server, the advertised DHCP option 6 (DNS Server) is verly likely the IP of the device running AdGuardHome itself, thus imho it's better to provide a dedicated settings field for users to specify where local PTR requests get sent to that is equivalent to an entry like this:

  [/10.in-addr.arpa/16.172.in-addr.arpa/168.192.in-addr.arp/17.172.in-addr.arpa/18.172.in-addr.arpa/19.172.in-addr.arpa/20.172.in-addr.arpa/21.172.in-addr.arpa/22.172.in-addr.arpa/23.172.in-addr.arpa/24.172.in-addr.arpa/25.172.in-addr.arpa/26.172.in-addr.arpa/27.172.in-addr.arpa/28.172.in-addr.arpa/29.172.in-addr.arpa/30.172.in-addr.arpa/31.172.in-addr.arpa/d.f.ip6.arpa]$LOCAL_RESOLVER_IP

Note: After some consideration, I think this is insufficient since a user might have multiple different subnets with different DHCP servers. Maybe we could do a blanket one that implies the rule above as that's what most users will likely use, and allow advanced users with more than one DHCP servers to set these up manually?

Here's a poor mock-up I made by messing with the HTML :stuck_out_tongue:

Note that AG Home is often configured to be the default resolver in /etc/resolv.conf. In light of this, we should make sure to not send those queries to AGH itself.

IMHO AGH could disable this feature automatically if it detects the PTR requests are being looped back to itself.

[dioey]

@wpehrc Interesting for my problem I now using static DNS on MikroTik router for the PTR request and I just released now on Clients (runtime) now showing my local client ip address, is that the right step? don't know, but this is enough for me

[ghost]

@dioey I do not know about RouterOS but if you need to stop NetworkManager from messing with your resolv.conf, you need to set dns=none according to https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html

[dioey]

@wpehrc this is the result of my config, don't know if this the right setup for PTR Request

[EntropySmoke]

If AdGuard Home is not a DHCP server, we should send those queries to the local resolver (which address we can obtain via DHCP ourselves). Additionally, we could allow configuring the local resolver address via AdGuardHome.yaml.

I am lost right there... Let's assume a simple/common/typical private network where you have one router and several clients, one of which is running AGH for the router and other local clients. In such a setup, the client running AGH is the local DNS resolver. What other resolver is there supposed to be?

AGH should also change the "Data on the clients that use AdGuard Home, but not stored in the configuration" under "Clients (runtime)" to something that makes more sense because with DHCP enabled, clients listed under "Clients (runtime)" are the one same ones added to the DNS Client list, making them part of the configuration.

I am also confused about the screenshot above showing "127.0.0.1 addresses" for Upstream DNS Servers. If AGH is running on 127.0.0.1, then wouldn't using the same 127.0.0.1 address for Upstream DNS Servers result in some infinite loop without any outbound WAN traffic?

Does configuring the client that runs AGH with static ARP have an effect on AGH ARP function? For example, Raspberry Pi itself can be configured to use Static ARP, but then what of AGH ARP?

[ghost]

I am lost right there... Let's assume a simple/common/typical private network where you have one router and several clients, one of which is running AGH for the router and other local clients. In such a setup, the client running AGH is the local DNS resolver. What other resolver is there supposed to be?

Here's a simple example. Let's suppose:

• You have a router running OpenWRT
• It's using the default 192.168.1.0/24 network range
• The device that runs AGH is at 192.168.1.2 listening on 0.0.0.0:53

On the openwrt device:

• dnsmasq is running a DHCPv4 and a DNS server at the same time
• We change DHCP option 6 (DNS Server) so the DHCP server advertises 192.168.1.2 as the DNS server. Now all of the well-behaving clients will send DNS requests directly to AGH.
• However, we still cannot disable dnsmasq's DNS server if we want AGH's hostname resolution feature to work, because AGH is not the DHCP server here, and thus it has no access to DHCP leases. It has to get this information from somewhere else, which is why it's sending PTR requests.
• dnsmasq running on the openwrt device is the correct DNS server to answer local (1.168.192.in-addr.arpa) PTR requests, because it's the network's DHCP server, and thus it has a list of hostname-ip pairs that it can look up.

I am also confused about the screenshot above showing "127.0.0.1 addresses" for Upstream DNS Servers. If AGH is running on 127.0.0.1, then wouldn't using the same 127.0.0.1 address for Upstream DNS Servers result in some infinite loop without any outbound WAN traffic?

For whatever reason this user seem to be running unbound on their local device. I do not know why do they need unbound but doing this essentially throws out half of AGH's valuable features (DoH/DoT/DNSCyrpt) out of the window.

[ghost]

@dioey Yes it looks correct. Please open a new issue if you need technical support.

[dioey]

@EntropySmoke for 127.0.0.1:5335 that unbound for DoT resolver and 127.0.0.1:5053 is for Cloudflared for DoH both using this guide https://docs.pi-hole.net/guides/dns/unbound/ and https://docs.pi-hole.net/guides/dns/cloudflared/ some how this setup reduce processing time in Query Log, yeah it kind of wasted but I just tried something from Pi-Hole guide before, I am using Pi-hole rather than AdGuard Home

[EntropySmoke]

I am lost right there... Let's assume a simple/common/typical private network where you have one router and several clients, one of which is running AGH for the router and other local clients. In such a setup, the client running AGH is the local DNS resolver. What other resolver is there supposed to be?

Here's a simple example. Let's suppose:

* You have a router running OpenWRT

* It's using the default 192.168.1.0/24 network range

* The device that runs AGH is at 192.168.1.2 listening on 0.0.0.0:53

On the openwrt device:

* dnsmasq is running a DHCPv4 and a DNS server at the same time

* We change DHCP option 6 (DNS Server) so the DHCP server advertises 192.168.1.2 as the DNS server. Now all of the well-behaving clients will send DNS requests directly to AGH.

* However, we still cannot disable dnsmasq's DNS server if we want AGH's hostname resolution feature to work, because AGH is not the DHCP server here, and thus it has no access to DHCP leases. It _has_ to get this information from somewhere else, which is why it's sending PTR requests.

* dnsmasq running on the openwrt device is the correct DNS server to answer local (1.168.192.in-addr.arpa) PTR requests, because it's the network's DHCP server, and thus it has a list of hostname-ip pairs that it can look up.

I am also confused about the screenshot above showing "127.0.0.1 addresses" for Upstream DNS Servers. If AGH is running on 127.0.0.1, then wouldn't using the same 127.0.0.1 address for Upstream DNS Servers result in some infinite loop without any outbound WAN traffic?

For whatever reason this user seem to be running unbound on their local device. I do not know why do they need unbound but doing this essentially throws out half of AGH's valuable features (DoH/DoT/DNSCyrpt) out of the window.

Thanks. I sort of get it, but I only have a consumer router that fortunately allows me to specify custom DNS resolver IP, a local AGH-running device in this case. It's a good router, but with limited closed-source features and without allowing to flash DD-WRT firmware. I don't know if it is running DNSMasq or some proprietary daemon. The only DHCP option on it is to either get Public IP, Subnet Mask, and Gateway IP from ISP or to input values into those 3 fields manually. It does have a field for "Domain name".

[ameshkov]

@wpehrc personally, I like your idea of adding a PTR resolver setting, but I'd better allow having multiple resolvers there, and also allow using "per-domain" syntax so that you could have something like this:

# Default PTR resolver
10.0.0.1
# For 192.168.*
[/168.192.in-addr.arpa/]192.168.0.1

There's also a use case when AGH runs on a public server. In theory, public clients' hostnames need to be resolved via the "Upstream DNS servers", not the "PTR resolver". I am not sure how to make it clear to users UX-wise.

[EntropySmoke]

How to tell whether PTR local host or PTR in-addr.arpa local client IP identifiers leaked upstream or not? Here's a set of screenshots when AdGuard DoH is the upstream DNS, AdGuard Home is DHCP Server, and local clients + router are added in Static Leases with host names: https://i.ibb.co/XyvM5qP/PTR1.png https://i.ibb.co/H7zZSgr/PTR2.png

Was that PTR record sent upstream to AdGuard DNS with leaked identifying information (local IP address and/or local host name assigned in Static Leases)?

[ghost]

personally, I like your idea of adding a PTR resolver setting, but I'd better allow having multiple resolvers there, and also allow using "per-domain" syntax so that you could have something like this:

# Default PTR resolver
10.0.0.1
# For 192.168.*
[/168.192.in-addr.arpa/]192.168.0.1

Oh totally, I was not implying there should be only one resolver, that was just a simplified example. What I was trying to say was we should perhaps separate this out from the custom DNS rules to make this easier to configure.

There's also a use case when AGH runs on a public server. In theory, public clients' hostnames need to be resolved via the "Upstream DNS servers", not the "PTR resolver". I am not sure how to make it clear to users UX-wise.

Currently AGH is already sending PTR requests to the upstream resolver, the issue we have only concerns private networks, as in we should not forward PTR requests of private addresses to upstream public resolvers unless the user explicitly configured AGH to do so. (kind of like this: https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml#L322 )

## Immediately respond to queries for local zones instead of leaking them to
## upstream resolvers (always causing errors or timeouts).
block_undelegated = true

[ameshkov]

Re-assigned to v0.106 since this is a breaking change.

[kour1er]

@ameshkov sorry to jump in on this thread - I've been following along and tried to use the "Specifying upstreams for rDNS" directions but when I do this, dns resolution dramatically slows. I'm sure I'm doing something dumb :) My setup is router at 10.0.0.1, AdGuard Home (using AdGuard Home DHCP) on another machine at 10.0.0.3. My upstream setting is:

[/0.10.in-addr.arpa/]10.0.0.3 https://dns.cloudflare.com/dns-query https://dns.quad9.net/dns-query quic://dns-unfiltered.adguard.com:784 https://dns.nextdns.io/31672b

If I remove the [/0.10.in-addr.arpa/]10.0.0.3 line, resolution speed goes back to normal. Any pointers as to what I might be doing wrong? Thanks!

(I'm using Adguard Home V0.106.0-b.1)

[zadigre]

Hello all!

I installed the 0.106 edge channel build on my RPI to test this new feature for PTR records. local PTR request works fine... except when there's not records found... in this case, requests timeout after 5 seconds (5000ms). Instead of the usual 5-10ms average response time shown on the main page, I now see 50ms or more. Since than, some of my homekit automation for wifi light switches are slow to start or do not start at all. Also, device names are no longer shown in the query log.

Is this a know problem with the current build?

[EugeneOne1]

@zadigre, the value of 5000ms will be reduced in the nearest volume of changes for this issue. The feature is not ready yet. We'll take a look at the devices' names problem as well.

[EugeneOne1]

Thank you all for your participation. The feature is included in v0.106.0.

[EugeneOne1]

Hello everyone! We've came up with a little update. The syntax of upstreams for resolving PTRs for local addresses is now fully equivalent to usual upstreams' field. The feature is now useful and works completely as it was designed.

[zadigre]

Hello everyone! We've came up with a little update. The syntax of upstreams for resolving PTRs for local addresses is now fully equivalent to usual upstreams' field. The feature is now useful and works completely as it was designed.

I have the latest edge build installed... but I still get long timeout on some local PTR records even if they are present in my DHCP leases... record present in leases... 48:e1:e9:xx:xx:xx 192.168.25.50 Meross Smart Plug if I do a nslookup on this IP address... I get connection timed out on my client ... but now, this request doesn't even appear in the query log. it does this will all 7 ip addresses assigned assigned to meross devices. all other I've tried are working fine. and same timeout if I try with an IP address not assigned by the adguard dhcp server.

if I put these meross devices in the static dhcp list, it works fine... but still get this timeout for IP addresses not yet assigned.

[ainar-g]

@zadigre, the edge build was still going when Eugene wrote that comment. Sorry for the confusion. The actual build with the feature should be out now.

[zadigre]

@zadigre, the edge build was still going when Eugene wrote that comment. Sorry for the confusion. The actual build with the feature should be out now.

good! works fine now... no timeout... I get a servefail for non existing PTR work now.

only "bug" is now for my meross device... if I do nslookup on the IP address, I get the servfail even if dhcp lease is present... if I put the MAC address and IP address in the static list, all is fine.

[zadigre]

I may have found the cause of this problem... 48:e1:e9:24:94:26 192.168.25.18 Meross Smart Switch hostname has spaces between words. this is the default hostname (and not changeable) reported by the device with the dhcp request. adguard probably doesn't not like this space. is there anything you could do to fix this or solution is to assign a static IP address?

[ainar-g]

@zadigre, thanks for the report. Weird behaviour from that device. Unless it's urgent, we'll try to fix it closer on Monday, as most of our team has already signed off for the weekend. Until then, the static lease solution is probably the best workaround.

[zadigre]

for sure, it's not urgent. I'll put the static lease for now anyways.

thank you!

[EntropySmoke]

The new system appears to be even more confusing. Setup:

• WAN router is 10.0.0.0, Raspberry Pi is 10.0.0.1 and is local DNS server, LAN clients are 10.0.0.2-10.0.0.9
• WAN router (10.0.0.0) and LAN clients (10.0.0.2-10.0.0.9) specify Raspberry Pi IP (10.0.0.1) for DNS server. In other words, 10.0.0.1 is my DNS server address for both LAN and WAN.
• Raspberry Pi is running AGH and uses 127.0.0.1 in DHCPD.conf for DNS server address
• AGH listens on 10.0.0.1 and 127.0.0.1 (set in AdGuardHome.yaml)
• AGH uses public AdGuard DoH servers for "Upstream DNS Servers"
• All clients and router are listed and labeled in Raspberry Pi etc/hosts

I am not hosting any services over WAN, not running AGH as public server, only use AGH for local clients, but I do use AGH for WAN DNS to block router-specific requests. What address should I use for the new "Private DNS Servers"? 127.0.0.1? 10.0.0.0?

If I use 127.0.0.1 for "Private DNS Servers" and run "Test Upstreams", I do get a 1.0.0.127 PTR response, but there is no PTR response if I use router 10.0.0.0 address "Private DNS Servers".

Previous AGH version shows a single PTR response resolution for my public IP address whenever my ISP assigns me a new public IP address. New AGH version shows NXDOMAIN whenever my ISP assigns me a new public IP address. Which AGH version displays correct behavior for my configuration, where AGH is DNS server for LAN clients and WAN?

[ainar-g]

@EntropySmoke

If AGH on the Pi is the DHCP server of the network, and all clients are listed in the /etc/hosts file on the Pi, then you don't need to enter anything there, as AGH should reply to all PTR queries about the private IPs it is aware of (thanks to /etc/hosts) without forwarding them anywhere.

I'm not sure I understand the second question, sorry. Do you mean that the PTR queries that come from your private network and request information about the public IP of the WAN Router return results that are different from the previous version? Because the behaviour of such queries shouldn't change, and we should still forward them to the upstreams.

[EntropySmoke]

1) AGH is not DHCP server, only local DNS server meant only for local non-public network. Router is DHCP server. Router DHCP settings specify Raspberry Pi local IP (10.0.0.1) for DHCP DNS assignment AND for WAN DNS assignment. Router assigns static DHCP lease to each client, including Raspberry Pi. Each client also uses static configuration and is set to use Raspberry Pi local DNS IP for DNS server, except for Raspberry Pi, which has static IP, but runs AGH on Loopback Interface IP 127.0.0.1 (Localhost) and has 127.0.0.1 for DNS address in DHCPD.conf. Router and clients connect to Raspberry Pi on IP 10.0.0.1, a private IP address. Raspberry Pi connects to AGH Service via Loopback Interface IP 127.0.0.1 (Localhost). How are local network PTR requests supposed to be resolved - via local IP 10.0.0.1 or via Loopback Interface 127.0.0.1 (Localhost) if AGH is not DHCP server?

2) With last AGH version, if ISP changed my public WAN IP to 1.2.3.4, then AGH resolved 4.3.2.1.in-addr.arpa domain upstream. With new AGH version, AGH stopped resolving in-addr.arpa ISP-assigned public WAN IP's upstream and began issuing NXDOMAIN instead.

[ainar-g]

@EntropySmoke

1. If you have clients' hostnames in the /etc/hosts file on the Pi, and there are no other clients that need private PTR resolving, you can still leave the field empty. If there are additional clients, for example the ones that only the WAN router knows about, you should add the address of the router's DNS resolver in there, which is probably 10.0.0.0 in your case.

2. I see. We haven't changed any logic regarding external IP addresses, at least as far as I know. Are you sure that the IP address that the ISP in question assigns to the WAN router is not withen one of the private or special purpose ranges? You could also send the IP address in question, along with verbose logs to devteam@adguard.com.

If none of that helps, please file a new issue or discussion with a link to this one. Thanks.

[kour1er]

Just to provide some feedback, the new Private DNS Servers (PTR) functionality that was added in 0.106.0-b.2 is working perfectly for me so far - it's fix the Bonjour issues I was seeing. Thanks for the great work

[EntropySmoke]

@EntropySmoke

1. If you have clients' hostnames in the `/etc/hosts` file on the Pi, and there are no other clients that need private PTR resolving, you can still leave the field empty.  If there are additional clients, for example the ones that only the WAN router knows about, you should add the address of the router's DNS resolver in there, which is probably `10.0.0.0` in your case.

2. I see.  We haven't changed any logic regarding external IP addresses, at least as far as I know.  Are you sure that the IP address that the ISP in question assigns to the WAN router is not withen one of the private or special purpose ranges?  You could also send the IP address in question, along with [verbose logs](https://github.com/AdguardTeam/AdGuardHome/wiki/FAQ#verboselog) to [devteam@adguard.com](mailto:devteam@adguard.com).

If none of that helps, please file a new issue or discussion with a link to this one. Thanks.

1. "Router's DNS Resolver" - I don't understand this part. In router settings, the only DNS IP that is set is Raspberry Pi's local DNS IP 10.0.0.1 because it is the one that runs AGH. Raspberry Pi IP 10.0.0.1 is the IP for router's "DHCP Name Server" for local clients and router's "WAN DNS". Router IP 10.0.0.0 is also in etc/hosts listed as client with its own hostname.
2. I'll send logs regarding that one.

[ShlomiD83]

Hi All, I didn't understand what I'm supposed to enter in the private DNS server address. I'm running AGH on a raspberry pi & my router is the DHCP server with the pi's address as the primary DNS in the DHCP options. which address should I use? the Pi? the router/DHCP server? please advise.

[EugeneOne1]

@ShlomiD83, judging by your setup, this field should contain the address of your router (which is DHCP in your network). But you may also leave it empty, because AGH should get it automatically.

[ShlomiD83]

@ShlomiD83, judging by your setup, this field should contain the address of your router (which is DHCP in your network). But you may also leave it empty, because AGH should get it automatically.

Ok, thank you.

[EntropySmoke]

What AGH needs is:

1. Better documentation or simpler explanation (because Private DNS Server Address field when AGH is already your private local DNS server service running on your private local DNS server device like Raspberry Pi is just plain confusing, especially when your router's DHCP settings already specify IP of you already private local DNS server device for LAN and WAN)
2. Simple UI and Advanced UI toggle
3. Re-wording of "Data on the clients that use AdGuard Home, but not stored in the configuration" because all client IP's and host names in that section are very much stored in AGH (AdGuardHome.yaml) configuration.

A bit off-topic, but is there an advantage to using PTR instead of etc/hosts file in a system where all LAN IP's are static? is it more secure to use DHCP Static Leases with PTR rather using DHCP Static Leases with etc/hosts assignments?

I also noticed that when AGH is DHCP with Static Leases (and etc/hosts file does not list clients), my LAN clients show ARP as source, but WLAN clients show DHCP as source even when WLAN devices have static IP's assigned in their device settings.