07 would be greatly appreciated. joel
On 2/24/16 10:27 PM, Stephen Farrell wrote: > > Hi David, > > All of those changes look good to me. Happy to clear the discuss > when you post -07. > > Cheers, > S. > > On 25/02/16 01:12, Dave Lawrence wrote: >> Stephen Farrell writes: >>> Section 11.3, I like that we're recommending that ECS be >>> disabled by default, but want to check one thing. This says: >>> "Due to the high cache pressure introduced by ECS, the feature >>> SHOULD be disabled in all default configurations." Does that >>> mean that all servers SHOULD disable this by default or does >>> this only apply to some servers? If the former, it should >>> probably be (re-)stated somewhere early on and more prominently >>> and not only stated far down in the document like this. If the >>> latter, then I think you need to be more precise and I'd like to >>> know why we're not preferring the more privacy friendly option >>> as our default. So I hope your answer is "yeah, all servers and >>> sure we can state that earlier as well" :-) >> >> In the draft that is pending its (presumably) final edits to make >> version -07 to head to the RFC Editor, the last paragraph of the >> Privacy Note (which is section 2), now says: >> >> 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. >> >> Does that adequately address your concern? >> >>> - abstract: I think it'd be good if the abstract noted that this >>> was documenting a deployed option and not necessarily >>> recommending this as the best thing ever. There's text in the >>> write-up and intro that does that nicely that could work if >>> reduced to one sentence, e.g. maybe something like: "This >>> documents an EDNS0 option that is in active use on the Internet >>> today that is intended to be revised in the near future to >>> improve it's security and privacy features." >> >> How is this for the new abstract? >> >> This document describes an EDNS0 extension that is in active use >> to carry information about the network that originated a DNS >> query, and the network for which the subsequent response can be >> cached. Since it has some known operational and privacy >> shortcomings, a revision will be worked through the IETF for >> improvement. >> >>> - 7.2.2 says "Because a client that did not use an ECS option >>> might not be able to understand it, the server MUST NOT provide >>> one in its response." That seems like a bit of a pity - one >>> comment I was going to make was that it might be good to include >>> this (or something) in a response so that a client that didn't >>> ask for ECS could be informed that some DNS server is doing ECS. >>> Would that actually break things? >> >> I don't think anyone has real experimental evidence on this. We do >> see a lot of variation in the way that various DNS servers handle EDNS >> in general, but I believe pretty much all of it has been with regard >> to how servers handle EDNS anomalies in requests, and not with its >> unexpected presence in responses. >> >> Given the lack of experience in this area I'd be reluctant to include >> anything about it in this document, but will certainly consider >> looking into it more for the revision. >> >>> - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. >>> RFC6598 at all. RFC6890 has a MAY associated with it, but does >>> refer to 6598. And what about stuff like RFC7534, which isn't >>> mentioned? Is that all correct and up to date? >> >> I believe it is good as-is; we actually have known operational use >> cases of allowing things like CGNAT through because a co-operating >> resolver and authority have shared information about what the network >> looks like. This is covered a little in the section on NAT >> Considerations. If there's still something problematic I'd be happy >> to address it. >> >>> - 11.1, 4th para: "Users" isn't really right. People don't know >>> about any of this stuff really. "Clients" would be more accurate >> >> Rephrased from: >> >> Users who wish their full IP address to be hidden can include an >> ECS option specifying the wildcard address (i.e. SOURCE >> PREFIX-LENGTH of 0). >> >> to: >> >> Users who wish their full IP address to be hidden need to configure >> their client software, if possible, to include an ECS option >> specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). >> >> Good? >> > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
