Alissa Cooper writes: > I support Stephen's DISCUSS point. My assumption in reading the > recommendation is that all recursive resolvers are recommended to disable > ECS by default.
Please confirm that this new paragraph at the end of the privacy section, written in response to Stephen's message, addresses your concerns as well: We recommend that the feature be turned off by default in all nameserver software, and that operators only enable it explicitly in those circumstances where it provides a clear benefit for their clients. We also encourage the deployment of means to allow users to make use of the opt-out provided. Finally, we recommend that others avoid techniques that may introduce additional metadata in future work, as it may damage user trust. > = Section 1 = > "The > motivation for a user to configure such a Centralized Resolver varies > but is usually because of some enhanced experience, such as greater > cache security or applying policies regarding where users may > connect." > > Assuming by "user" you mean end user of the DNS, I think this would make > more sense if it said "user or ISP" or something like that. I assume it's > much more common for ISPs to explicitly choose to use centralized > resolvers than for end users to do so. I think you're probably right, even taking into consideration that the original motivation for this came from OpenDNS and Google running resolvers that users had to affirmatively select. Either way, I've changed the text from: motivation for a user to configure such a Centralized Resolver varies to motivation for having such Centralized Resolvers varies Does this work? > = Section 2 = > Given that you reference specific implementations in various places in > the document, would be interesting to note any specific implementations > that surface the opt-out choice to users. An excellent point. As far as I know, getdns is the only stub resolver currently offering it, thanks to Daniel Kahn Gillmor at the last Hackathon. Is it acceptable to say "regrettably" about something in an RFC? I could put this in as the final paragraph of the Privacy Note: Regrettably, support for the opt-out provisions of this specification are currently limited. Only one stub resolver, getdns, is known to be able to originate queries with anonymity requested, and as yet no applications are known to be able to indicate that user preference to the stub resolver. > = Section 5 = > > s/client location/client network location/ Done. > = Section 7.2.1 = > > "A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH > indicates that the provided prefix length was not specific enough to > select the most appropriate Tailored Response. Future queries for > the name within the specified network SHOULD use the longer SCOPE > PREFIX-LENGTH." > > I think it would help to expand a bit about using the exception case for > the SHOULD here. It seems to me that this basically involves a judgment > call by the operator of the recursive resolver between exposing a longer > prefix or providing less useful information to an authoritative resolver > that is indicating that it needs more information. But setting SOURCE > PREFIX-LENGTH involved a judgment call in the first place about the > privacy protection involved in providing a less-than-full address. So how > is a recursive resolver supposed to decide whether to follow the > indication from the authoritative resolver about prefix length? Agreed that it is a bit wishy-washy. I added this sentence to the end of the quoted paragraph: Factors affecting whether the Recursive Resolver would use the longer length include the amount of privacy masking the operator wants to provide their users, and the additional resource implications for the cache. Is that okay? I'm unsure whether it warrants further expansion. I've felt (without hard evidence) that in practical terms it would actually be unusual for a caching resolver to dynamically change its policy for future requests based on longer scope lengths. I mean sure, if the recursive sent up a truncated source length (say,v4 /16) from their normal policy of /24 because of a user option, then the authoritative will come back at /24 or whatever and the recursive will subsequently use /24 anyway because that's their default policy. But I'm doubtful that same resolver being told /25 in a response would then switch to using /25 in future queries. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
