On 07.10.17 19:39, jpmvtd...@laposte.net wrote:
> It looks like this package could introduce vulnerabilities if not
> handled properly, because it provides more than just local DNS cache.
Unless you have a particular reason to use "dnsmasq", I strongly suggest
you use "unbound"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/08/2017 09:17 AM, Ralph Seichter wrote:
> Unless you have a particular reason to use "dnsmasq", I strongly suggest
> you use "unbound" (https://www.unbound.net) instead.
May I asked, why you prefer unbound ? AFAIK there's pdns-recursor which
On 08.10.17 11:46, Toralf Förster wrote:
> May I asked, why you prefer unbound ?
The OP was concerned than dnsmasq "could introduce vulnerabilities if
not handled properly, because it provides more than just local DNS
cache". In contrast, Unbound has a single purpose(*), and I found it to
be a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/08/2017 05:41 AM, Igor Mitrofanov wrote:
> Here's what I personally recommend:
> # DNS servers
>
> no-resolv
>
> no-poll
>
> no-hosts
>
> server=8.8.4.4
>
> server=8.26.56.26
>
> server=74.82.42.42
>
> server=64.6.64.6
>
>
On 08.10.17 09:47, Toralf Förster wrote:
> IMO there's absolutely no advantage of using external DNS servers.
"No advantage" is putting it too mildly. Manually specifying upstream
servers runs contrary to the very reason to have a resolver on the Tor
node in the first place, which is to only
On 08.10.17 18:34, Igor Mitrofanov wrote:
> Unless configured otherwise, Dnsmasq chooses a server from the list
> randomly, so the more servers the operator specifies in dnsmasq.conf,
> the less traffic each server gets.
The "proper" way, meaning the way resulting in the smallest surface for
> Parenthetically, even setting up a https://littlefreelibrary.org at my
> condominium complex has been met with incomprehension and fear...
Easier for them to do that than realize the many $thousands
they paid for their education which could have been free.
Indoctrination withdrawal syndrome is
My hosting provider runs no DNS servers and recommends using 8.8.x.x,
so I have to pick something.
On Sun, Oct 8, 2017 at 10:22 AM, Ralph Seichter wrote:
> On 08.10.17 18:34, Igor Mitrofanov wrote:
>
>> Unless configured otherwise, Dnsmasq chooses a server from the list
On Wed, Aug 9, 2017 at 4:08 PM, Alexander Nasonov wrote:
> m...@eugenemolotov.ru wrote:
>> After that check from which ip it was logged in. This probably
>> would be ip of the exit node.
>
> What if they "bridge" mitm-ed traffic to a different host?
>
> I saw a similar ssh
On 08.10.17 20:48, Igor Mitrofanov wrote:
> Unbound's upstream requests can be intercepted and used in traffic
> correlation just like any other.
I thought I expressed myself clearly enough, but I'll try one more time.
Unbound, or any other resolver, can either a) perform the recursive
lookup or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/08/2017 07:03 PM, Igor Mitrofanov wrote:
> Toralf, thanks for the data. Has that 10% stabilized, or is it still
> growing for your node?
No, it is rather decreasing over time.
I'm just too lazy till now to switch to another DNS cache, which
On 08.10.17 19:48, Igor Mitrofanov wrote:
> My hosting provider runs no DNS servers and recommends using 8.8.x.x,
> so I have to pick something.
You don't have to pick, and this is not meant to be patronising. Install
Unbound with the few lines of configuration I posted earlier in this
thread,
Please see the RFC that describes the recursive resolution algorithm:
https://tools.ietf.org/html/rfc1034.
Unbound is a simple recursive resolver. If it does not know the IP, it
has to ask - there is no way around asking. The fact that you do not
know what network links Unbound relies on ("just
Unless configured otherwise, Dnsmasq chooses a server from the list
randomly, so the more servers the operator specifies in dnsmasq.conf,
the less traffic each server gets. This increases the diversity of DNS
requests, complicating traffic analysis for any adversary that
controls some, but not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/08/2017 06:34 PM, Igor Mitrofanov wrote:
> With a large-enough cache and sufficient uptime dnsmasq effectively
> becomes a mini-DNS server that stores IP addresses for the vast
> majority of sites that Tor users ever visit.
NAK, just 10,000
Toralf, thanks for the data. Has that 10% stabilized, or is it still
growing for your node?
On Sun, Oct 8, 2017 at 9:54 AM, Toralf Förster wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/08/2017 06:34 PM, Igor Mitrofanov wrote:
>> With a large-enough
On 08.10.17 22:40, teor wrote:
> This is only true if your resolver implements QNAME minimisation [...]
> Does the version of the recursive resolver you're using do this?
Unbound implements this, and via qname-minimisation-strict one can
even disable the default fallback of sending full QNAME
El 08/10/17 a las 09:17, Ralph Seichter escribió:
> On 07.10.17 19:39, jpmvtd...@laposte.net wrote:
>
> > It looks like this package could introduce vulnerabilities if not
> > handled properly, because it provides more than just local DNS cache.
>
> Unless you have a particular reason to use
On 08.10.17 21:40, jpmvtd...@laposte.net wrote:
> Disclaimer : this is a (too) big email.
Seriously? Can you really not answer to individual messages? ;-)
> it is not necessarily better to ask directly to a root name server.
Yes it is; for uncached lookups, one of the root zone servers must be
>> # Only listen on loopback
>>
>> interface=lo
>> bind-interfaces
>
> What is your opinion about the config line "listen-address=127.0.0.1" advised
> in https://wiki.debian.org/HowTo/dnsmasq#Local_Caching ?
It should have a similar effect, except that 127.0.0.1 is IPv4 only,
while "interface=lo"
Ralph, you seem to be more concerned with minimizing the number of
hosts involved in a DNS lookup, and you (correctly) believe that
running a recursive resolver yourself, as opposed to delegating it,
decreases that number. If a DNS provider like Hurrican Electric is
your main concern, then I think
Hello,
Thanks for your interest. Disclaimer : this is a (too) big email.
Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 03:41:19 UTC 2017:
> 2. You can start by editing /etc/dnsmasq.conf as follows:
>
>
On 08.10.17 21:23, Igor Mitrofanov wrote:
> you seem to be more concerned with minimizing the number of hosts
> involved in a DNS lookup, and you (correctly) believe that running a
> recursive resolver yourself, as opposed to delegating it, decreases
> that number.
Yes, that's what I have been
On 8 Oct 2017, at 16:24, Ralph Seichter wrote:
>> who is aware of the query is not all that matters ; the apparent
>> origin of the query also matters, depending of the position of the
>> attacker.
>
> Sure, but keep in mind: Even if an attacker could gain access to
Hello,
Thanks for your interest. Disclaimer : this is a (too) big email.
Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 03:41:19 UTC 2017:
> 2. You can start by editing /etc/dnsmasq.conf as follows:
>
>
25 matches
Mail list logo