On Mon, 25 May 2020 20:37:07 -0700
Andy Ruhl wrote:
> So I'm not big into DNS and I don't have a firm grasp on all of these
> techniques, but I have an idea.
>
> This is all just a big game of who are you hiding from right? If you
> hide from your ISP, now you have to trust the DNS server
aa...@zadzmo.org ("Aaron B.") writes:
>This isn't really a thing where I live. The ISP's here routinely return
>A records to a scammy "search engine" instead of NXDOMAIN.
Yes, that was very popular here. But, also for legal reasons, the
providers only manipulated the answers of their own DNS
So I'm not big into DNS and I don't have a firm grasp on all of these
techniques, but I have an idea.
This is all just a big game of who are you hiding from right? If you
hide from your ISP, now you have to trust the DNS server provider. Who
among them are to be trusted?
For example I'm pretty
At Mon, 25 May 2020 19:51:52 -0400, "Aaron B." wrote:
Subject: Re: Securing DNS traffic
>
> Again, I'd prefer to run my own resolvers, but can't justify the
> expense.
I would recommend begging or borrowing _any_ old used computer that can
run any open-source OS (though ideall
On Mon, 25 May 2020 12:57:59 +0200
Niels Dettenbach wrote:
> I would trust my (paid) ISPs NS much more then any other "free" one by all
> what i've seen in my life there - especially if your ISP grants you no usage
> logging by contract.
This isn't really a thing where I live. The ISP's here
Sad Clouds wrote in
<20200525152338.beed20b18e42642ec3403...@gmail.com>:
|On Fri, 22 May 2020 22:38:19 +0100
|Sad Clouds wrote:
|
|> It seems there are two main security enhancements for DNS:
|>
|> 1. DNSSEC - digital signatures for DNS records to verify they haven't
|> been tampered
Am Sonntag, 24. Mai 2020, 20:02:45 CEST schrieb Aaron B.:
> I'm also worried about this, but also fear datamining by my ISP. So I
> completely ditched Google, and split my queries between Cloudflare and
> Quad9 - neither gets the complete picture.
This relys on a typical misunderstanding what most
Am Samstag, 23. Mai 2020, 12:09:09 CEST schrieb Sad Clouds:
> I was thinking about this as well, but is there any real evidence that
> public DNS providers misuse your personal data?
Depends from what you "expect" as "misuse".
Running "free" public NS to i.e. "just collect domain names" and
On Fri, 22 May 2020 22:38:19 +0100
Sad Clouds wrote:
> It seems there are two main security enhancements for DNS:
>
> 1. DNSSEC - digital signatures for DNS records to verify they haven't
> been tampered with.
>
> 2. DNS over TLS - encryption of DNS traffic for privacy. This goes via
> port
On Mon, 25 May 2020 10:17:56 +0200
Jörn Clausen wrote:
> Hi!
>
> I was not arguing for "no security at all". It's just this motivation
> for DoT/DoH (disguising the request from your ISP) that I don't get.
>
> I have only a cursory knowledge of these technologies, but I think
> DNSSEC is the
Hi!
I was not arguing for "no security at all". It's just this motivation for
DoT/DoH (disguising the request from your ISP) that I don't get.
I have only a cursory knowledge of these technologies, but I think DNSSEC
is the far better approach against the type of forgery you mentioned. Why
do
On Sun, 24 May 2020 20:55:29 +0200
Jörn Clausen wrote:
> I simply don't get how this is a use case for DoT or DoH. Even if you
> disguise the DNS lookup, the next packet you send will be directed to
> the address you just looked up. Unless this happens to be a virtual
> hosting service, it is
Hi!
I'm also worried about this, but also fear datamining by my ISP. So I
> completely ditched Google, and split my queries between Cloudflare and
> Quad9 - neither gets the complete picture.
>
I simply don't get how this is a use case for DoT or DoH. Even if you
disguise the DNS lookup, the
On Sat, 23 May 2020 11:38:18 +0200 (CEST)
Havard Eidnes wrote:
> If you desire to protect your lookup history from prying eyes, it's
> one thing to protect the communication itself. However, I would
> personally shy away from all of Google, Cloudflare and Mozilla
> recursors, DoH or not.
I'm
On Sun, 24 May 2020 11:00:00 +0200 (CEST)
Havard Eidnes wrote:
> Nope. There is no specified protocol to direct recursive
> resolution to use TLS towards specific authoritative servers.
> There has been talk about this on the DNSOP IETF working group,
> but nothing has been agreed. This means
>> Plus, of course, the outgoing queries from your recursor will
>> be in cleartext.
>
> OK, so I understand that root servers probably won't support
> TLS, but some authoritative servers may support TLS (aka
> ADoT). But I don't seem to find a way to tell unbound "use TLS
> opportunistically,
On Sat, 23 May 2020 11:38:18 +0200 (CEST)
Havard Eidnes wrote:
> With your own recursor which implements query minimization, and by
> having multiple clients actively using it, you leak far less about
> your lookup history than by forwarding all your full DNS client
> queries to one of the
>> What I'm not sure about is this - unbound(8) has "root-hints" that
>> points to root DNS servers and it will handle recursive queries, but it
>> can also specify "forward-zone" where it can forward to Cloudflare or
>> Google recursive DNS servers. Both of these solution would resolve DNS
>>
On Sat, 23 May 2020 11:38:18 +0200 (CEST)
Havard Eidnes wrote:
> If you desire to protect your lookup history from prying eyes, it's
> one thing to protect the communication itself. However, I would
> personally shy away from all of Google, Cloudflare and Mozilla
> recursors, DoH or not.
I was
Looking at the responses to my original email and doing some further
research, the summary of pluses/minuses would be:
1) unbound(8) resolving via root DNS servers
+ Most accurate results, since it bypasses any intermediaries.
- Increased lookup time and higher load on authoritative DNS
On Sat, May 23, 2020 at 3:08 AM Sad Clouds wrote:
>...
> > > What I'm not sure about is this - unbound(8) has "root-hints" that
> > > points to root DNS servers and it will handle recursive queries,
> > > but it can also specify "forward-zone" where it can forward to
> > > Cloudflare or Google
On Fri, 22 May 2020 20:05:40 -0400
Jeffrey Walton wrote:
> On Fri, May 22, 2020 at 5:38 PM Sad Clouds
> wrote:
> >
> > ...
> > What I'm not sure about is this - unbound(8) has "root-hints" that
> > points to root DNS servers and it will handle recursive queries,
> > but it can also specify
On Fri, May 22, 2020 at 5:38 PM Sad Clouds wrote:
>
> ...
> What I'm not sure about is this - unbound(8) has "root-hints" that
> points to root DNS servers and it will handle recursive queries, but it
> can also specify "forward-zone" where it can forward to Cloudflare or
> Google recursive DNS
On Fri, 22 May 2020 22:38:19 +0100
Sad Clouds wrote:
> So which one of them takes precedence and under what conditions?
> Why have both active at the same time? Is one option better/more secure
> than the other?
I would advise not doing both at the same time. Pick one model, which
model depends
On Fri, May 22, 2020 at 10:38:19PM +0100, Sad Clouds wrote:
>
> 2. DNS over TLS - encryption of DNS traffic for privacy. This goes via
> port 853 and could be over TCP or UDP (DTLS), although it's not clear
> to me if both TCP and UDP are always supported, of if it's mainly TCP.
>
Assuming dns
I've got some spare time on my hands, so I decided to educate myself on
how to secure DNS traffic. I have a small home network with various
devices and most of them use public (Cloudflare or Google) DNS servers.
It seems there are two main security enhancements for DNS:
1. DNSSEC - digital
26 matches
Mail list logo
