Il 29 novembre 2019 01:40 Kenji Baheux ha scritto:
On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <
tirumaleswarreddy_ko...@mcafee.com> wrote:
Subject: [EXTERNAL] Re: [dns-privacy] Trying to understand DNS resolver
'discovery'
On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy
mailto:tirumaleswarreddy_ko...@mcafee.com>>
wrote:
In addition, with the extended error codes defined in
https://tools.ietf.org/html/draf
-privacy On Behalf Of Andrew Campling
Sent: Thursday, November 28, 2019 3:39 AM
To: Livingood, Jason ; Stephane Bortzmeyer
; dns-privacy@ietf.org
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
CAUTION: External email. Do not click links or open attachments unless you
to understand DNS resolver 'discovery'
On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer"
mailto:dns-privacy-boun...@ietf.org%20on%20behalf%20of%20bortzme...@nic.fr>>
wrote:
>For instance, if your access provider has a lying resolver
I just wanted to ta
On 11/27/19, 9:55 AM, "dns-privacy on behalf of Neil Cook"
wrote:
>> If you use DoH/DoT, it is because you don't trust the access network.
>It says nothing about whether you trust the access network.
[JL] I agree with Neil. IMO the use of encrypted DNS is orthogonal to whether
or not you trust
On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer"
wrote:
>For instance, if your access provider has a lying resolver
I just wanted to take a moment to note that choosing to use the term 'lying'
when describing resolver behavior is unnecessarily negative and seems
> -Original Message-
> From: Neil Cook
> Sent: Wednesday, November 27, 2019 8:25 PM
> To: Stephane Bortzmeyer
> Cc: Konda, Tirumaleswar Reddy ;
> dns-privacy@ietf.org; Phillip Hallam-Baker
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
&
Please see inline
From: Neil Cook
Sent: Wednesday, November 27, 2019 8:10 PM
To: Konda, Tirumaleswar Reddy
Cc: Stephane Bortzmeyer ; dns-privacy@ietf.org; Phillip
Hallam-Baker
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
CAUTION: External email. Do not click
> On 27 Nov 2019, at 14:28, Stephane Bortzmeyer wrote:
> If you use DoH/DoT, it is because you don't trust the access network.
It says nothing about whether you trust the access network. You *may* be using
DoH/DoT because you don’t trust the access network. However, you may trust the
access
On Wed, Nov 27, 2019 at 10:04:57AM +,
Neil Cook wrote
a message of 45 lines which said:
> I don’t see why they’re broken by design;
You explained it well:
> they add no security properties
> on top of the (insecure) DHCP mechanism used to contact the resolver
> in the first place
And
> -Original Message-
> From: Stephane Bortzmeyer
> Sent: Wednesday, November 27, 2019 7:59 PM
> To: Konda, Tirumaleswar Reddy
> Cc: Stephane Bortzmeyer ; Phillip Hallam-Baker
> ; dns-privacy@ietf.org
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'di
> On 27 Nov 2019, at 14:22, Konda, Tirumaleswar Reddy
> wrote:
>
>>
>> Resolver discovery schemes allow a client to ask the local resolver to
>> provide
>> information about the resolver, such as DoH info, as well as potentially
>> other
>> information about the resolver. I don’t see why
On Wed, Nov 27, 2019 at 09:07:15AM +,
Konda, Tirumaleswar Reddy wrote
a message of 72 lines which said:
> > *All* "automatic discovery of the DoH resolver" schemes are broken
> > by design and I really wonder why people keep suggesting them.
>
> Not all discovery mechanisms have security
> -Original Message-
> From: Neil Cook
> Sent: Wednesday, November 27, 2019 7:48 PM
> To: Konda, Tirumaleswar Reddy
> Cc: Phillip Hallam-Baker ; dns-privacy@ietf.org
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
>
> CAUTION: Exte
> -Original Message-
> From: dns-privacy On Behalf Of Neil Cook
> Sent: Wednesday, November 27, 2019 3:35 PM
> To: Stephane Bortzmeyer
> Cc: dns-privacy@ietf.org; Phillip Hallam-Baker
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
>
>
> -Original Message-
> From: dns-privacy On Behalf Of Neil Cook
> Sent: Wednesday, November 27, 2019 3:02 PM
> To: Phillip Hallam-Baker
> Cc: dns-privacy@ietf.org
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
>
> CAUTION: External e
> On 26 Nov 2019, at 18:04, Stephane Bortzmeyer wrote:
>
>> Of these three models, I have always considered (1) to be a security
>> hole.
>
> I fully agree. *All* "automatic discovery of the DoH resolver" schemes
> are broken by design and I really wonder why people keep suggesting
> them.
> On 26 Nov 2019, at 17:35, Phillip Hallam-Baker wrote:
>
> So what I see is a requirement for DNS resolver configuration. We already
> have rfc6763 to tell us how to get from a DNS label to an Internet service.
> Albeit one that presupposes the existence of a resolution mechanism. I don't
> -Original Message-
> From: dns-privacy On Behalf Of Stephane
> Bortzmeyer
> Sent: Tuesday, November 26, 2019 11:35 PM
> To: Phillip Hallam-Baker
> Cc: dns-privacy@ietf.org
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
>
>
to
encrypt the DNS messages exchanged between the local DNS server and recursive
resolver.
Cheers,
-Tiru
From: dns-privacy On Behalf Of Brian Dickson
Sent: Tuesday, November 26, 2019 11:21 PM
To: Phillip Hallam-Baker
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] Trying to understand DNS resolver
Hi Phillip,
Nice summary, Please see inline
From: dns-privacy On Behalf Of Phillip
Hallam-Baker
Sent: Tuesday, November 26, 2019 11:05 PM
To: dns-privacy@ietf.org
Subject: [dns-privacy] Trying to understand DNS resolver 'discovery'
CAUTION: External email. Do not click links or open
On Tue, Nov 26, 2019 at 1:08 PM Stephane Bortzmeyer
wrote:
> On Tue, Nov 26, 2019 at 12:35:13PM -0500,
> Phillip Hallam-Baker wrote
> a message of 166 lines which said:
>
> > 2) Admin/User Configured DNS
> > The client obtains the information to connect to a resolver through
> an
> >
On Tue, Nov 26, 2019 at 10:13 AM Stephane Bortzmeyer
wrote:
> On Tue, Nov 26, 2019 at 09:51:14AM -0800,
> Brian Dickson wrote
> a message of 98 lines which said:
>
> > However, if the only place the client is able to establish an
> > encrypted path to is a forwarder, this leave open the
On Tue, Nov 26, 2019 at 09:51:14AM -0800,
Brian Dickson wrote
a message of 98 lines which said:
> However, if the only place the client is able to establish an
> encrypted path to is a forwarder, this leave open the possibility
> that the forwarder->(forwarder->[...])->resolver might involve
On Tue, Nov 26, 2019 at 12:35:13PM -0500,
Phillip Hallam-Baker wrote
a message of 166 lines which said:
> 2) Admin/User Configured DNS
> The client obtains the information to connect to a resolver through an
> Administrator or User configuration action. This may be inserting an IP
>
On Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker
wrote:
> This notion of DNS resolver discovery seems very strange to me.
>
The larger issue (and the one I am interested in finding solutions for) is
that what is configured as a 'resolver', might actually be a 'forwarder'.
I.e. the path is
This notion of DNS resolver discovery seems very strange to me. There are
three ways in which a DNS resolver can be realistically determined by a
client whether that is in the platform (Windows/OSX/Linux/etc) or the
application.
1) Promiscuous DNS
The client obtains the information to connect
27 matches
Mail list logo
