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.
<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/C3A2B481-10AF-4FD4-B361-BD133F344953%40gmail.com.

Reply via email to