Re: [Last-Call] [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Dec 18, 2019 at 6:10 PM Eric Rescorla <ekr@xxxxxxxx> wrote:

“It has been pointed out that should the trend towards using large public resolvers increase, an increased centralisation of DNS resolution services will result.

Well, it's been pointed out, but it's not at all clear that it's true, due to the large amount of centralization of ISPs in certain areas, so no, I don't think this document should make this claim.

Agree.

 
An increasing number of applications are offering application-specific encrypted DNS resolution settings, rather than defaulting to using only the system resolver. Due to a lack of a standardized discovery mechanism for DoH and Strict DoT servers, applications that do so are currently limited to using hard coded lists of resolvers and a variety of heuristics and resolvers are available in different applications. At the time of writing, efforts to provide standardized signalling mechanisms for applications to also discover the services offered by local resolvers are in progress [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of ISPs are deploying encrypted DNS, for example see the Encrypted DNS Deployment Initiative [EDDI].

I'm not sure what the point of this text is, but it seems kind of confusing. In particular, it's not the case that the primary reason that Firefox uses a hardcoded list is because there is no standardized discovery mechanism.

The text also relates discovery to encryption. That seems odd. Is it the case that some parties didn't mind which DNS server was used, as long as the traffic was unencrypted?

 

Everything after this just seems to pre-empt discussions that are ongoing and haven't reached consensus.


Application-specific changes to default destinations for users' DNS queries might increase or decrease user privacy - it is highly dependant on the network context and the application-specific default. This is an area of active debate.

In order that users are aware of and can control such changes it is highly desirable that applications

Is it "highly desirable", though?
 
* communicate clearly the change in default to users

Not clearly true, since the status quo is often not clearly communicated.
 
* provide configuration options to change the default

Doesn't seem like that is always desirable. Some routers and networks don't offer configuration options, but that doesn't mean they should be obeyed. It's complicated.
 
* provide configuration options to always use the network provided resolver

"network provided resolver" is not well-defined.
 
thanks,
Rob

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux