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
