[Q] Is it expected to have plenty PTR queries emanating from the device running AGH?

deekerman commented

2026-03-04 01:54:47 -05:00

Owner

Originally created by @KaoDome on GitHub (Dec 22, 2020).

(I hope it's the right place to ask questions too...)

Prerequisites

[✓ ] I am running the latest (stable) version
[✓ ] I checked the documentation and found no answer
[✓ ] I checked to make sure that this issue has not already been filed

Setup info

I have AdGuard Home on a Raspberry Pi 3 model B, running Arch for ARM devices (Linux 5.8.9-2-ARCH, aarch64). It is running headless and its only purpose is to run AGH, WiFi and BT radios are disabled and it's connected via Ethernet to the router.

DNS setting is done per-device, although I could set the router to use the static IP of the Pi for the primary DNS by default I'm using 1.1.1.1 and 9.9.9.9.

Problem description

Stats retention are set to 7 days so the following pictures are more or less representative or a typical usage, some devices are Windows machines running the full version of AdGuard and a couple just the browser extension too besides ADH:

Note that the top client is the Raspberry itself, but its queries (aside from when it's updating) seem to be PTR to LAN clients, and rather continuous, for lack of a better word:

Actual question

Is it expected? If not, any idea on what could be happening or misconfigured? Arch per se is rather barebones, so I don't discard it being something that needs to be changed in a config file or via a systemd binary call.

By the way, the contents of /etc/resolv.conf would be:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.1
nameserver 192.168.1.1
search .

Originally created by @KaoDome on GitHub (Dec 22, 2020). ### _(I hope it's the right place to ask questions too...)_ ### Prerequisites [✓ ] I am running the latest **(stable)** version [✓ ] I checked the documentation and found no answer [✓ ] I checked to make sure that this issue has not already been filed ### Setup info I have AdGuard Home on a Raspberry Pi 3 model B, running Arch for ARM devices (Linux 5.8.9-2-ARCH, aarch64). It is running headless and its only purpose is to run AGH, WiFi and BT radios are disabled and it's connected via Ethernet to the router. DNS setting is done per-device, although I could set the router to use the static IP of the Pi for the primary DNS by default I'm using 1.1.1.1 and 9.9.9.9. ### _Problem_ description Stats retention are set to 7 days so the following pictures are more or less representative or a typical usage, some devices are Windows machines running the full version of AdGuard and a couple just the browser extension too besides ADH: ![Dashboard view](https://user-images.githubusercontent.com/61412446/102933131-f8d40500-44a1-11eb-8358-02773c572421.png) Note that the top client is the Raspberry itself, but its queries (aside from when it's updating) seem to be PTR to LAN clients, and rather continuous, for lack of a better word: ![Query log for the device running AdGuard Home](https://user-images.githubusercontent.com/61412446/102933474-94fe0c00-44a2-11eb-9991-2900d896e143.png) ### Actual question Is it expected? If not, any idea on what could be happening or misconfigured? Arch per se is rather barebones, so I don't discard it being something that needs to be changed in a config file or via a _systemd_ binary call. By the way, the contents of `/etc/resolv.conf` would be: ``` # This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients directly to # all known uplink DNS servers. This file lists all configured search domains. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.1 nameserver 192.168.1.1 search . ```

deekerman

2026-03-04 01:54:47 -05:00

closed this issue
added the
question
label

deekerman commented

2026-03-04 01:54:54 -05:00

Author

Owner

@ameshkov commented on GitHub (Dec 23, 2020):

It's hard to answer as I am not sure who sends this queries.

If there's a local resolver that can answer these PTR queries, you may want to configure AdGuard Home to send them to that resolver. Something like this:
[/in-addr.arpa/]192.168.0.1

https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#specifying-upstreams-for-domains

@ameshkov commented on GitHub (Dec 23, 2020): It's hard to answer as I am not sure who sends this queries. If there's a local resolver that can answer these PTR queries, you may want to configure AdGuard Home to send them to that resolver. Something like this: `[/in-addr.arpa/]192.168.0.1` https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#specifying-upstreams-for-domains

deekerman commented

2026-03-04 01:54:57 -05:00

Author

Owner

@KaoDome commented on GitHub (Dec 23, 2020):

I see, so it's not expected to see that kind of traffic.

There's another resolver in the network, the router itself is running dnsmasq and acts as the default resolver for any new device that connects to the network (it uses 1.1.1.1 and 9.9.9.9 internally), but I think I don't have it configured properly because the log of AdGuard Home still shows PTR queries emanating from the Pi every 10 minutes on the dot after adding [/in-addr.arpa/]192.168.1.1. Since the router is the one that's assigning the IPs it should be able to answer those queries and nslookup using it as the DNS server doesn't seem to work throwing outputs like this:

> 214.1.168.192.in-addr.arpa
Server:  OpenWrt.lan
Address:  192.168.1.1

*** OpenWrt.lan can't find 214.1.168.192.in-addr.arpa: Non-existent domain

I noticed that systemd-resolved was running as well on the Pi and I don't think it would be needed since AdGuard Home is the one binding to 53, so I disabled that service. After a reboot, it looks alright from a port perspective:

[Kao@Pi ~]$ sudo lsof -i -P -n | grep LISTEN
AdGuardHo 329            root   15u  IPv6   5872      0t0  TCP *:80 (LISTEN)
AdGuardHo 329            root   22u  IPv6   1831      0t0  TCP *:53 (LISTEN)
sshd      331            root    3u  IPv4   6551      0t0  TCP *:22 (LISTEN)
sshd      331            root    4u  IPv6   6553      0t0  TCP *:22 (LISTEN)

And to be honest there isn't much else running in there:

For now though I'm still seeing the same PTR queries every 10 minutes, so after the reboot I made sure to be logged out of the web interface, in case that was the element making those queries.

I'll give it some time and do some research on dnsmasq, OpenWrt and the like to see if there's anything to be done in there in the meantime and report if I find anything else.

@KaoDome commented on GitHub (Dec 23, 2020): I see, so it's not expected to see that kind of traffic. There's another resolver in the network, the router itself is running `dnsmasq` and acts as the default resolver for any new device that connects to the network (it uses 1.1.1.1 and 9.9.9.9 internally), but I think I don't have it configured properly because the log of AdGuard Home still shows PTR queries emanating from the Pi every 10 minutes on the dot after adding `[/in-addr.arpa/]192.168.1.1`. Since the router is the one that's assigning the IPs it should be able to answer those queries and `nslookup` using it as the DNS server doesn't seem to work throwing outputs like this: ``` > 214.1.168.192.in-addr.arpa Server: OpenWrt.lan Address: 192.168.1.1 *** OpenWrt.lan can't find 214.1.168.192.in-addr.arpa: Non-existent domain ``` I noticed that `systemd-resolved` was running as well on the Pi and I don't think it would be needed since AdGuard Home is the one binding to 53, so I disabled that service. After a reboot, it looks alright from a port perspective: ``` [Kao@Pi ~]$ sudo lsof -i -P -n | grep LISTEN AdGuardHo 329 root 15u IPv6 5872 0t0 TCP *:80 (LISTEN) AdGuardHo 329 root 22u IPv6 1831 0t0 TCP *:53 (LISTEN) sshd 331 root 3u IPv4 6551 0t0 TCP *:22 (LISTEN) sshd 331 root 4u IPv6 6553 0t0 TCP *:22 (LISTEN) ``` And to be honest there isn't much else running in there: ![Pi Htop](https://user-images.githubusercontent.com/61412446/103015620-10ae9600-4541-11eb-8515-90e5d2276c24.png) For now though I'm still seeing the same PTR queries every 10 minutes, so after the reboot I made sure to be logged out of the web interface, in case that was the element making those queries. I'll give it some time and do some research on `dnsmasq`, OpenWrt and the like to see if there's anything to be done in there in the meantime and report if I find anything else.

deekerman commented

2026-03-04 01:54:57 -05:00

Author

Owner

@KaoDome commented on GitHub (Dec 23, 2020):

I am still getting to the bottom of it, but I realized something that could be somewhat related.

I am not positive this is the case, but as of now the PTR queries are still happening at 10 min. intervals, but only for the clients that use AdGuard Home, "but are not stored in the configuration". It means those that are not manually added as clients, right?

The interesting bit is that they are manually added to the clients list (identified by IP, the important devices have static leases stablished in the DHCP server of the router), but they show an appended string: .lan

Since the reboot I mentioned earlier I believe the rest of the devices that can be seen in the Clients list above that don't appear below have yet to connect to the network again.

That .lan suffix seems to be the name for the local domain as seen in the DHCP settings of the router:

I'm going to rename one of the clients above, Luna, to "Luna.lan" temporarily and see if its PTR query is gone afterwards. It's not pretty, but it's a mitigation for now until everything clears up.

By the way, I'm sorry if whatever I post seems obvious or makes one think duh!, I'm a newbie when it comes to networking and jumped right into OpenWrt and AdGuard Home without understanding many things of the underlying tech/programs.

@KaoDome commented on GitHub (Dec 23, 2020): I am still getting to the bottom of it, but I realized something that could be somewhat related. I am not positive this is the case, but as of now the PTR queries are still happening at 10 min. intervals, but only for the clients that use AdGuard Home, "but are not stored in the configuration". It means those that are not manually added as clients, right? The interesting bit is that they are manually added to the clients list (identified by IP, the _important_ devices have static leases stablished in the DHCP server of the router), but they show an appended string: `.lan` ![Clients view](https://user-images.githubusercontent.com/61412446/103038075-c7287000-456d-11eb-8523-71fe28bd6f79.png) Since the reboot I mentioned earlier I believe the rest of the devices that can be seen in the Clients list above that don't appear below have yet to connect to the network again. That `.lan` suffix seems to be the name for the local domain as seen in the DHCP settings of the router: ![Local domain](https://user-images.githubusercontent.com/61412446/103038320-7107fc80-456e-11eb-80c6-79f36024f8e1.png) I'm going to rename one of the clients above, Luna, to "Luna.lan" temporarily and see if its PTR query is gone afterwards. It's not pretty, but it's a mitigation for now until everything clears up. By the way, I'm sorry if whatever I post seems obvious or makes one think _duh!_, I'm a newbie when it comes to networking and jumped right into OpenWrt and AdGuard Home without understanding many things of the underlying tech/programs.

deekerman commented

2026-03-04 01:54:57 -05:00

Author

Owner

@gerroon commented on GitHub (Dec 27, 2020):

It's hard to answer as I am not sure who sends this queries.

If there's a local resolver that can answer these PTR queries, you may want to configure AdGuard Home to send them to that resolver. Something like this:
[/in-addr.arpa/]192.168.0.1

https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#specifying-upstreams-for-domains

Thanks for the sugesstion. I tried it and it does not work (I still get those queries). I have Pihole running on another pc and so I tried

[/in-addr.arpa/]192.168.2.1 (Pihole IP)

The queries seems to come from the same PC that is running the Adguard server (192.168.2.6), so itself

@gerroon commented on GitHub (Dec 27, 2020): > It's hard to answer as I am not sure who sends this queries. > > If there's a local resolver that can answer these PTR queries, you may want to configure AdGuard Home to send them to that resolver. Something like this: > `[/in-addr.arpa/]192.168.0.1` > > https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#specifying-upstreams-for-domains Thanks for the sugesstion. I tried it and it does not work (I still get those queries). I have Pihole running on another pc and so I tried `[/in-addr.arpa/]192.168.2.1` (Pihole IP) The queries seems to come from the same PC that is running the Adguard server (192.168.2.6), so itself

deekerman commented

2026-03-04 01:54:57 -05:00

Author

Owner

@ameshkov commented on GitHub (Dec 27, 2020):

@gerroon well, it does exactly what it is configured to - sends PTR requests to the IP that belongs to Pi-hole. It is not supposed to solve this and forbid your devices to send those queries.

The question is why are these queries being sent in the first place?

@KaoDome

but only for the clients that use AdGuard Home, "but are not stored in the configuration". It means those that are not manually added as clients, right?

Yeah, that's right. For clients that are added to AdGuard Home, it is able to respond to these queries, maybe what's these devices expect. Again, it's unclear why and what software triggers PTR queries.

@ameshkov commented on GitHub (Dec 27, 2020): @gerroon well, it does exactly what it is configured to - sends PTR requests to the IP that belongs to Pi-hole. It is not supposed to solve this and forbid your devices to send those queries. The question is why are these queries being sent in the first place? @KaoDome > but only for the clients that use AdGuard Home, "but are not stored in the configuration". It means those that are not manually added as clients, right? Yeah, that's right. For clients that are added to AdGuard Home, it is able to respond to these queries, maybe what's these devices expect. Again, it's unclear why and what software triggers PTR queries.

deekerman commented

2026-03-04 01:54:57 -05:00

Author

Owner

@KaoDome commented on GitHub (Jan 5, 2021):

I'm sorry for the delay, these days have been rather busy family-wise and I couldn't allocate much time to this.

While I couldn't find out exactly why it happens (the root cause so to speak), I'm happy to see everything working correctly as of now and what I needed to do for it to work as usual.

TL;DR version: systemd-resolved was key in this, both when running and not running. Ensure a sane /etc/resolv.conf is present and AdGuard Home will behave as expected (or rather, the system as a whole).

When systemd-resolved is enabled and running that file is symlinked to /run/systemd/resolve/resolv.conf with the contents I posted earlier. If I were to point the finger at something I'd say that having the first name-server being the local machine is what made those queries appear in AdGuard Home.

When I disabled that service, the symbolic link remained, but it was pointing to a non-existing file, because no process was running to generate /run/systemd/resolve/resolv.conf. I kept on seeing PTR queries and tried to look at how I could find out the process that was producing them, but to no avail. tcpdump could track them when filtering port 53 UDP traffic on the Ethernet interface but because they were really quick I found no way to correlate those connections with a process PID using other tools (netstat, ss, etc.).

I looked at the CLI version ot Wireshark too but that was too complex to me. Reinstalling the OS and AdGuard Home didn't change anything, since the problem lied elsewhere.

Looking again at the resolv.conf file was fortuitous, but it was then that I realized it was pointing nowhere (so it was essentially empty) and I wrote a very basic one pointing to the router's IP where dnsmasq is running:

nameserver 192.168.1.1

And that's it, that's all it took. From that point on no more PTR queries were logged by AdGuard Home and I didn't even need to add an upstream definition for the in-addr.arpa domain.

I have still have no idea what the origin of the queries is, I'm guessing they keep happening every 10 minutes, but whatever it is, it's using /etc/resolv.conf and the router is able to answer those queries so the AdGuard Home log remains clean of them and relevant.

I'm writing from a machine running Linux now and the contents of /etc/resolv.conf as generated by NetworkManager are similar, it only has an extra line (search lan) referring to the local domain attached to the hosts connected to the router, but it seems not to be necessary.

I may try to add that line to the file in the Pi too where AdGuard Home is running to see if "Clients (runtime)" is cleared because the machines that appear there are registered manually in the Clients section above, but so far so good. It's running smoothly.

I'm going to leave this thread opened for a couple of days to let people see the solution and then close it as the issue has been resolved.

@KaoDome commented on GitHub (Jan 5, 2021): I'm sorry for the delay, these days have been rather busy family-wise and I couldn't allocate much time to this. While I couldn't find out exactly why it happens (the root cause so to speak), I'm happy to see everything working correctly as of now and what I needed to do for it to work as usual. **TL;DR version: `systemd-resolved` was key in this, both when running and not running. Ensure a sane `/etc/resolv.conf` is present and AdGuard Home will behave as expected (or rather, the system as a whole).** When `systemd-resolved` is enabled and running that file is symlinked to `/run/systemd/resolve/resolv.conf` with the contents I posted earlier. If I were to point the finger at something I'd say that having the first name-server being the local machine is what made those queries appear in AdGuard Home. When I disabled that service, the symbolic link remained, but it was pointing to a non-existing file, because no process was running to generate `/run/systemd/resolve/resolv.conf`. I kept on seeing PTR queries and tried to look at how I could find out the process that was producing them, but to no avail. `tcpdump` could track them when filtering port 53 UDP traffic on the Ethernet interface but because they were really quick I found no way to correlate those connections with a process PID using other tools (`netstat`, `ss`, etc.). I looked at the CLI version ot Wireshark too but that was too complex to me. Reinstalling the OS and AdGuard Home didn't change anything, since the problem lied elsewhere. Looking again at the `resolv.conf` file was fortuitous, but it was then that I realized it was pointing nowhere (so it was essentially empty) and I wrote a very basic one pointing to the router's IP where `dnsmasq` is running: ``` nameserver 192.168.1.1 ``` And that's it, that's all it took. From that point on no more PTR queries were logged by AdGuard Home and I didn't even need to add an upstream definition for the `in-addr.arpa` domain. I have still have no idea what the origin of the queries is, I'm guessing they keep happening every 10 minutes, but whatever it is, it's using `/etc/resolv.conf` and the router is able to answer those queries so the AdGuard Home log remains clean of them and relevant. I'm writing from a machine running Linux now and the contents of `/etc/resolv.conf` as generated by NetworkManager are similar, it only has an extra line (`search lan`) referring to the local domain attached to the hosts connected to the router, but it seems not to be necessary. I may try to add that line to the file in the Pi too where AdGuard Home is running to see if "Clients (runtime)" is cleared because the machines that appear there are registered manually in the Clients section above, but so far so good. It's running smoothly. I'm going to leave this _thread_ opened for a couple of days to let people see the solution and then close it as the issue has been resolved.

deekerman referenced this issue

2026-03-04 02:12:19 -05:00

Slow query log for filters "blocked *" #2687

deekerman referenced this issue

2026-03-04 02:19:44 -05:00

Large stats.db causes slowdowns in DNS lookups #2753

deekerman referenced this issue

2026-03-04 02:29:02 -05:00

Removing leases.db unsets client-requests data #2836

deekerman referenced this issue

2026-03-04 02:32:11 -05:00

Ability to download logs #2863