As a happy end, I installed unbound on the WeeWX machine with an added local zone to allow the machine to see a couple of local targets needed for backup and NTP. pihole is happy and the stats are relevant now without all the WeeWX lookups.
On Thursday, January 4, 2024 at 2:49:52 PM UTC-5 Joel Bion wrote: > Further thoughts: > > When I think of even the more complexly configured servers, they may > support email, web services, things like that. This means they are, for > network use purposes, frequently responsive to a remote request vs. > primarily generative of traffic for their own reasons.Many data generative > applications that maintain a regular stream of data to a remote host open > that stream only once - and on reconnect if needed, for any reason. > > weather data sensors and collection applications that feed to weather data > storage sites are data generators for this discussion’s purposes and > neither client nor server distributions are optimized for them. > > Further, to save resources on a sensor, and on the machine receiving the > sensory data, rarely is any lasting connection (in an TCP/UDP way) > established. In fact, in some, like weather underground, the authentication > credentials and the sensory payload are given in a single packet, using > HTTP GET or whichever. Single packet updates. > > Pihole and other tools that provide recursive DNS resolvers are typically > done in external boxes - not installed in typical “server” installations. > This is usually great, but isn’t so great for the data generator use case. > > to avoid hammering other devices, one of a couple things are done on the > data generator box, all in the spirit of “fix the problem as close to the > creator of the problem as possible” > > A) a recursive DNS server is placed resident on the data generating box - > this fixes the problem at the box level but adds complexity for end users. > Tools like metro bridge/meteohub where a turnkey box+utility run should > probably do this. > > B) the application generating the traffic is built to try to be a gentle > user of DNS by doing its own caching. > > I’m a big fan of (A) because writing a barely functional DNS resolver for > single-application use is easy but writing a really good one requires a lot > of subtle domain-specific (pun intended) knowledge. And there are excellent > examples like unbound+getdns+stubby (and others!) that do it so well. > > Joel > > Sent from my iPhone > > On Jan 4, 2024, at 10:14 AM, G Hammer <[email protected]> wrote: > > I am happy enough with sending the DNS lookups external. > > Saves configuring pihole to not log/ignore those calls. > If misconfigured, it ran for literally years with no warnings until the > infernal WU lookups were pointed it way. > Seems happy enough now. > > <pihole.png> > > > On Thursday, January 4, 2024 at 1:04:57 PM UTC-5 Vince Skahan wrote: > >> I might add that I've been running 'dig' a lot on my system this morning >> while constructing my previous answer, and I 'do' see my pihole caching. >> Many answers are from cache. When the TTL has expired it looks up to >> google. So it's working as expected. Again, if your pihole is out of >> compute I'd suggest your pihole is misconfigured somehow. >> >> (I'm running mine in docker on a several year old i3 NUC that is >> basically at zero load average) >> >> -- > You received this message because you are subscribed to the Google Groups > "weewx-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-development/1ad89bff-c8fe-4f37-a4f5-6ca4213fc322n%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-development/1ad89bff-c8fe-4f37-a4f5-6ca4213fc322n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > <pihole.png> > > -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/6e63aabf-9451-4950-8878-0b11c8f1486an%40googlegroups.com.
