Constant localhost DNS querys for Google

[Markfree]

With a RT-AX86U router, I'm noticing some "google.com" DNS lookups from 127.0.0.1 every few minutes on the AdGuard dashboard.
I have blocked them and have not experienced any issues thus far.

However, I am still unsure which process is generating this constant traffic.

With TCPDump, I'm using the following query

tcpdump -n -i any 'host 127.0.0.1 and udp port 53'
19:21:36.042492 lo    In  IP 127.0.0.1.56844 > 127.0.0.1.53: 13269+ A? google.com. (28)
19:21:36.043174 lo    In  IP 127.0.0.1.53 > 127.0.0.1.56844: 13269 1/0/0 A 0.0.0.0 (44)
19:21:36.043241 lo    In  IP 127.0.0.1.56844 > 127.0.0.1.53: 14805+ AAAA? google.com. (28)
19:21:36.043444 lo    In  IP 127.0.0.1.53 > 127.0.0.1.56844: 14805 1/0/0 AAAA :: (56)
19:21:36.043922 lo    In  IP 127.0.0.1.49283 > 127.0.0.1.53: 22747+ PTR? 0.0.0.0.in-addr.arpa. (38)
19:21:36.044838 lo    In  IP 127.0.0.1.53 > 127.0.0.1.49283: 22747 NXDomain* 0/0/0 (38)
19:21:36.053413 lo    In  IP 127.0.0.1.55009 > 127.0.0.1.53: 55743+ A? www.google.com. (32)
19:21:36.053476 lo    In  IP 127.0.0.1.55009 > 127.0.0.1.53: 57279+ AAAA? www.google.com. (32)
19:21:36.054163 lo    In  IP 127.0.0.1.53 > 127.0.0.1.55009: 57279 1/0/0 AAAA :: (60)
19:21:36.054210 lo    In  IP 127.0.0.1.53 > 127.0.0.1.55009: 55743 1/0/0 A 0.0.0.0 (48)

Now, I need to find out which process is generating these DNS requests. Does anyone know what it might be or have any tips to share?

 

[dave14305]

It comes from the Adguardhome script’s netcheck function.

Asuswrt-Merlin-AdGuardHome-Installer/AdGuardHome.sh at 0fb6fcf572d6e5072f44aef7cd32e61aa0207561 · jumpsmm7/Asuswrt-Merlin-AdGuardHome-Installer

The Official Installer of AdGuardHome for Asuswrt-Merlin - Asuswrt-Merlin-AdGuardHome-Installer/AdGuardHome.sh at 0fb6fcf572d6e5072f44aef7cd32e61aa0207561 · jumpsmm7/Asuswrt-Merlin-AdGuardHome-Inst...

github.com

 

[Markfree]

Nice!

Let me see if I got it and, please, correct me if I'm wrong.

The function first checks if the system date is sort of up to date. If it is, the ALIVE var is set to 0. I wonder if you ever found a situation where the year was less than 1970...

Then, it pings Cloudflare and queries the "google.com" domain. If they are both reachable, the ALIVE var remains 0.
Finally, the third check is a Google web request which also sets the ALIVE var.

So, in my scenario, I believe the function is returning something other than 0, since AdGuard is blocking the second and third "if".

What is that function for anyway?
Why are there 3 checks?
Would you mind clarifying that for me, please?

 

[SomeWhereOverTheRainBow]

Nice!

Let me see if I got it and, please, correct me if I'm wrong.

The function first checks if the system date is sort of up to date. If it is, the ALIVE var is set to 0. I wonder if you ever found a situation where the year was less than 1970...

Then, it pings Cloudflare and queries the "google.com" domain. If they are both reachable, the ALIVE var remains 0.
Finally, the third check is a Google web request which also sets the ALIVE var.

So, in my scenario, I believe the function is returning something other than 0, since AdGuard is blocking the second and third "if".

What is that function for anyway?
Why are there 3 checks?
Would you mind clarifying that for me, please?

One checks the clocks time, 2 checks the dns, 3 checks the ability of your router to reach internet. If number 2, and 3 don't work, then you have a problem ( adguardhome watch dog restarts the actual adguardhome go binary to see if it has failed for some odd reason.) Number 3 check exist specifically for a case where your dns fails to return a response but somehow you are able to reach out to the web by other means. Either way, you trying to bypass these checks makes adguardhome script watch dog restart adguardhome at some point. Is your desire to understand how to break things a hobby? Or something you just do on your free time?

 

[SomeWhereOverTheRainBow]

With a RT-AX86U router, I'm noticing some "google.com" DNS lookups from 127.0.0.1 every few minutes on the AdGuard dashboard.
I have blocked them and have not experienced any issues thus far.
View attachment 49018

However, I am still unsure which process is generating this constant traffic.

With TCPDump, I'm using the following query

tcpdump -n -i any 'host 127.0.0.1 and udp port 53'
19:21:36.042492 lo    In  IP 127.0.0.1.56844 > 127.0.0.1.53: 13269+ A? google.com. (28)
19:21:36.043174 lo    In  IP 127.0.0.1.53 > 127.0.0.1.56844: 13269 1/0/0 A 0.0.0.0 (44)
19:21:36.043241 lo    In  IP 127.0.0.1.56844 > 127.0.0.1.53: 14805+ AAAA? google.com. (28)
19:21:36.043444 lo    In  IP 127.0.0.1.53 > 127.0.0.1.56844: 14805 1/0/0 AAAA :: (56)
19:21:36.043922 lo    In  IP 127.0.0.1.49283 > 127.0.0.1.53: 22747+ PTR? 0.0.0.0.in-addr.arpa. (38)
19:21:36.044838 lo    In  IP 127.0.0.1.53 > 127.0.0.1.49283: 22747 NXDomain* 0/0/0 (38)
19:21:36.053413 lo    In  IP 127.0.0.1.55009 > 127.0.0.1.53: 55743+ A? www.google.com. (32)
19:21:36.053476 lo    In  IP 127.0.0.1.55009 > 127.0.0.1.53: 57279+ AAAA? www.google.com. (32)
19:21:36.054163 lo    In  IP 127.0.0.1.53 > 127.0.0.1.55009: 57279 1/0/0 AAAA :: (60)
19:21:36.054210 lo    In  IP 127.0.0.1.53 > 127.0.0.1.55009: 55743 1/0/0 A 0.0.0.0 (48)

Now, I need to find out which process is generating these DNS requests. Does anyone know what it might be or have any tips to share?

BTW if you upgrade your adguardhome, it has away to ignore logging queries to these domains. There is no need to actually block them. When you could simply ignore them inside the adguardhome dns settings options.

Log ignore policy for Chatty Clients and/or domains · Issue #4299 · AdguardTeam/AdGuardHome

Okay, So I know on the Query page we can filter by both Domain and Client. What I am proposing is to add a policy for ignoring clients in the log and statistics. I came about this suggestion becaus...

github.com

 

[Martinski]

...
I wonder if you ever found a situation where the year was less than 1970...

A standard system clock would never return a year that is less than 1970 because the start time of the "Unix Epoch" is defined as 1970-01-01, UTC 00:00:00.

Just FYI.

 

[Markfree]

Fortunately, nothing has broken so far.
In my spare time, I'll continue to work on understanding how everything is running on my system.
Ignoring specific domains might help me unclutter my logs, so I'll look into that, but I'll keep the block in place anyway.
Thanks for clarifying that. I appreciate your opinion.