On Wed, May 09, 2018 at 10:18:10AM +0200, Martin Kepplinger wrote:
> On 2018-05-08 16:59, Jonathan Marquardt wrote:
> > On Tue, May 08, 2018 at 04:45:58PM +0200, Martin Kepplinger wrote:
> > > How does a usable ipset (hash:ip,port) look like, so that it is a
> > > whitelist
> > > for
> > > in/out
On Sat, 12 May 2018 08:54:00 +
nusenu wrote:
> "if you want to add a second DNS resolver as a fallback to your
> /etc/resolv.conf configuration, try to choose a resolver within your
> autonomous system and make sure it is not your first entry in that
> file (the first entry should be your loc
I don't know how everyone else feels about this - rather than using a
secondary resolver in the event Unbound fails - why not let the query
fail and the user have to try again? Is there any reason to risk letting
a third party resolver possibly log exit node DNS queries?
nusenu:
>
>
> Andrew Dea
Andrew Deason:
> An operator may think they're not "using" google's dns because they're
> pointed at localhost first, and their local resolver is working, so they
> shouldn't normally be using the fallback so it doesn't matter. Obviously
> that's not true, otherwise such relays wouldn't be identi
>> All our nodes are using a local DNS caching server and only use google
>> as a fallback.
>
> I was also using google just as a fallback; I've now changed my node to
> just use a local resolver, with no fallback.
>
> Neither the email from nusenu nor the documentation pointed to actually
> says