wow; I remember getting excited when someone ported Joust to PC so I didn't have to pay a quarter in an arcade. Free software has really stepped it up lately!
@Makyen and the way we're doing DNS Caching currently isn't portable to the way we're using the resolver class currently (so we can't use dns.resolver.Cache currently the way we're doing it - it needs to be reconfigured)
let's initialize the resolver overall at the beginning
with caching if we want it
which my PR does do
as part of it
and if caching is enabled (new config option!) we can then init the cache at runtime startup
and then that's global to the entire program via GlobalVars.dns which is a DNSResolver object which is just an extended __init__ to set the various config arguments inside the Resolver class
it's no different functionally - where 'functionality' changes is "How do we initialize the Resolver with cache?" and just do that at startup and refer to it everywhere (since everything pretty much does from globalvars import GlobalVars
the only time we'd want a 'custom' case without caching is the dig command
but in the cases of really fubar DNS configuration or a really bad DNS server, we don't override 'nameservers' in any way shape or form now so 'bad' records are stored in DNS Cache as well
so making things configurable (nameservers, cache enable/disable, cache cleaning time for a given record) is the primary goal first, which lets us then configure thread-safe DNS Caching if we want to
by default that's still going to be enabled
@Makyen but my PR offers the ability to disable the cache. Or to point to an external (Non-system) resolver. So if we're on a particularly janky/unstable System resolver, we can make it go specifically to Google, Quad9, etc. As well as implement the thread safe Cache as part of the Resolver() object as well (the init in DNSResolver class we have had for a long while handles setting that Cache variable if we say to enable caching, rather than us doing it manually.
@ThomasWard But, there's no need to have a separately defined global. The dnspython package already includes a global default_resolver which exists globally within all files which do import dns.resolver. We start our code in ws.py, so adding import dns.resolver and dns.resolver.get_default_resolver().cache = dns.resolver.Cache() near the top of that file sets up a cache for all future uses of the default_resolver (i.e. calls which are made to dns.resolver.resolve()) in all imports.
Although, I'd probably want !!/dig to report that the default resolver is producing a different result. Maybe show both the Google DNS result and the system result, if they are different.
@ThomasWard Yes, but one of the things we use it to investigate is why we're seeing strange results in the normal use of SD. Thus, one of the things we're looking for when using it is what SD is seeing for the domain. We're also interested in knowing what it should be seeing, and knowing if those are different.
@Makyen the only problem here is, in order to parse 'truthy' or 'falsy' statements we need something a-la setuptools.dist.strtobool() which is an extra requirements.txt entry. I'm trying to see if I can find an alternative.
if not i may have to write my own - I really don't want to import setuptools if we don't need it
I'd prefer not to import it too (I'd noted that you'd added and was wondering what issue it was resolving).
@ThomasWard I'm not sure what you're saying. Do you mean parsing entries in the config file which might be truthy or falsey? If so, we can just restrict what's valid to a limited subset.
Just lowercase it and compare. Then complain if it doesn't match one of the accepted inputs. Aren't we using a package that gives a portion of this capability in a config file? I'd have to double-check what it can do automatically.
@CodyGray hmmmm...any chance that was intended for a Teams instance? That doesn't make any sense, it requires a login "with your Namely account" and no way to create accounts
@CodyGray Also, and I realize it's 2 things in a row (I'm not targeting you, I promise ;)), but we don't generally give feedback on posts we report ourselves.
@CodyGray If you mention that you're watching a domain that was found in already-deleted spam right before/after you perform the watch command, I don't think anyone would give you flak for it (unless there are FPs existing on an SE search or w/e)
But that's the kind of stuff that just makes me feel like Charcoal's tools are what Alan Cooper calls "excise". Essentially, that they consume more time than value they are directly adding. It starts to feel like I'm putting in time and effort just to make the system happy, rather than to actually solve a problem. That's a big disconnect that I often have with other users in here, and I find it really off-putting.
I have a very limited amount of time available these days to do things that I'm not getting paid to do, so I guess that colors how I approach things.
@CodyGray That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command if you really want to add this pattern.
