100+K of PTR records after upgrade

Problem with Beta 5.0:
`https://tricorder.pi-hole.net/vurierlyh6
Update completed yesterday, from what I recall only web and FTL were showing updates available, however since then there are many entries showing PTR. I have tried rebooting router, Pi-hole onto avail. As of this morning, there are almost 700k entries.

I have not changed anything on my router running fresh tomato on RT68U where I have network settings as shown in attached snapshot that has been working for a very long time. There are many entries on router showing this error every 10 seconds

Mar 22 10:38:54 abcd daemon.warn dnsmasq[1316]: Maximum number of concurrent DNS queries reached (max: 150)
Mar 22 10:39:01 abcd daemon.warn dnsmasq[1316]: Maximum number of concurrent DNS queries reached (max: 150)
Mar 22 10:39:07 abcd daemon.warn dnsmasq[1316]: Maximum number of concurrent DNS queries reached (max: 150)
Mar 22 10:39:13 abcd daemon.warn dnsmasq[1316]: Maximum number of concurrent DNS queries reached (max: 150)
Mar 22 10:39:19 abcd daemon.warn dnsmasq[1316]: Maximum number of concurrent DNS queries reached (max: 150)


`

Debug Token:
https://tricorder.pi-hole.net/vurierlyh6

EDIT: place debug token correctly

Been playing around with different settings and the only way I can minimize so many PTR queries is by unchecking

Settings -> DNS -> Advanced DNS -> Use Conditional Forwarding

This does not allow to see hostnames of clients that I am living with now.

Additional steps taken though drastic -
Flush network on both pi-hole
Flush logs on both pi-hole (DO NOT DO THIS UNLESS YOU WANT TO LOSE ALL HISTORICAL DATA)

Any suggestions or options are welcome to bring this system to the way it was working prior to yesterday’s update.

Thanks

You may want to crossread Weird top domains, where similar stray mDNS lookups by Apple devices flooded the network when Conditional Forwarding was enabled.

Proposed solutions were blacklisting the associated lookups or providing a custom dnsmasq configuration file for the troubling domain names.

Thanks @Bucking_Horn

I created 99-extra-nxdomain.conf in /etc/dnsmasq.d/ with below entries as mentioned in other thread
server=/_aaplcache1._tcp.localdomain/
server=/_aaplcache2._tcp.localdomain/
server=/_aaplcache3._tcp.localdomain/
server=/_aaplcache4._tcp.localdomain/
server=/lb._dns-sd._udp.localdomain/

Everything seems to work now.

Big question is I haven’t added any Apple devices nor have I changed any config on any apple devices, have multiple MacProS, ipads, iphones, AppleTVs and somehow after upgrade yesterday it all blew up. Just wondering why it would do this?

We see this happening when you have told Pi-hole to use the router for the forwarding and then told the router to use Pi-hole for it’s DNS. You end up in a loop where Pi-hole asks the router for the information and the router doesn’t know so it asks Pi-hole, which then asks the router, etc, etc…

@DanSchaper - this is exactly the dilemma I was in originally, but somehow for past 6 months this has been working perfectly as it is where I plugged in 2 IP’s for Pi-Hole in DNS and also had both Pi-Hole enabled for Conditional Forwarding to get host names of all the users connected. Even after adding 5 entries @Bucking_Horn mentioned as of now since last time I cleared logs, both Piholes have about 125k entries each.

I even rebuilt my router from scratch to see if there was any issue but many entries persists.
Some entries that have showed up on dashboard for permitted domains are
db._dns-sd._udp.0.2.2.10.in-addr.arpa - 28208
lb._dns-sd._udp.parivar - 23502
lb._dns-sd._udp.0.2.2.10.in-addr.arpa - 9868
db._dns-sd._udp.parivar - 2038
b._dns-sd._udp.parivar - 4777
Almost same numbers on both pihole

I do not want to disable pihole and due to WFH requirement, it is imperative that I have working DNS as most of the sites take forever to load as both the router and pihole are swamped.

What I am not gathering is how was it working for 6+ months and to make things working well what is the option you or anyone on this forums suggest?

Appreciate your time.

Latest debit logs from both pihole if that helps someone assist me

https://tricorder.pi-hole.net/j3248igf5b
https://tricorder.pi-hole.net/he53d1i8er

Edit:add debug logs

If you are going to conditionally forward to 10.2.2.1 then make sure 10.2.2.1 does not use Pi-hole for it’s DNS.

Those lines seem to have been taken directly from a post on the topic with similar problems I linked above.

Note that I was encouraging you to read that post, rather than just copy and paste from it. It wouldn’t make sense to reiterate the full story here, so please take the time to fully examine that post. Naturally, you’d have to adopt your solution to the specific situation in your network.

Pi-hole for sure doesn’t create DNS traffic on your network - your clients do. Pi-hole just filters and forwards it.

Either your clients have only recently begun asking those queries (not very likely), or something in the way your network handles DNS among your router and Pi-hole has changed.

Since you’d always had Conditional Fowarding enabled, did you recently configure your router to use Pi-hole as its upstream DNS (thus allowing the loop DanSchaper mentioned)? Or has your router’s firmware been updated lately (which may have been the root cause for the other topic)?

Edit:
Since you mentioned Fresh Tomato: Seems Fresh Tomato’s latest release dates from 2020.03.20, so quite recently. I wouldn’t know if Fresh Tomato auto-updates, though.

As Fresh Tomato employs dnsmasq, it may be worth a try to restrict it to provide replies for local domain queries only from local sources (i.e. hosts file and DHCP).
The corresponding option for your local domain would be:

local=/parivar/

You’d have to consult your manuals on how exactly to configure this on Fresh Tomato, if possible at all.

And your debug logs show one of your Pi-hole’s (the homebridge one) as incapable of resolving DNS at all (via localhost, Pi-hole and public DNS alike), as well as several additional software (nginx, system-resolved, homebridge, hoobs, cloudflare, smbd, docker) running on both of them, at least partially, which may or may not play their part in closing a potential DNS loop. :thinking:

Thanks @DanSchaper & @Bucking_Horn. Although I did read i must not have paid attention to details it seems, goes to show what happens when panicked. Sorry for that.
You are right that freshtomato posted an update yesterday (thanks for the heads up) routers do not update automatically nor do I know of a way to make that happen. One thing I always do is check pihole -up on secondary pihole, update it and then update primary. Normally try to keep both at same level at all times. That is exactly what I did yesterday afternoon. Nothing new had been added/removed.

In any case, I have resorted to uncheck Conditional forwarding and will let this run as is by cross referencing host name from router.

Thanks for your patience.

@Bucking_Horn - if I may can you clarify where does “local=/parivar/” supposed to be added/entered?

That option is meant to be supplied to a dnsmasq instance.
My suggestion is purely based on Fresh Tomato advertising it contains dnsmasq.

dnsmasq details it as follows (click for more)

Quoted from dnsmasq man page:

tells dnsmasq that a domain is local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain to any upstream servers. –local is a synonym for –server to make configuration files clearer in this case.


With regards to Fresh Tomato, I am not familiar at all with that firmware.

Fresh Tomato may expose a corresponding setting via its UI, may allow you to supply it via a generic custom option for dnsmasq or may require you to manually locate and edit a dnsmasq configuration file on your router.

As mentioned, you’d have to check your firmware’s manual or documentation for how exactly to configure this on Fresh Tomato, if possible at all.