Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-08

[Ballot comment]

Thanks for handling my discuss point and the comments
below (which I didn't check in detail, but am happy to
chat about it you want).

Cheers,
S.


- 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." 

- Thanks for section 2.

- 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?

- 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?

- 11.1, 4th para: "Users" isn't really right. People don't know
about any of this stuff really. "Clients" would be more accurate

[Ballot comment]
I agree with the following suggestions from Russ Housley's Gen-ART review:

In Section 6, I think it would be useful to say that the SCOPE
PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE
PREFIX-LENGTH from the request.

In Section 7.3, last paragraph, last sentence, I think that "should"
ought to be in all capital letters.

In Section 7.4, fourth paragraph, last sentence, I think that
"recommended" ought to be in all capital letters.

[Ballot comment]
I agree with Stephen's DISCUSS, and his comment about mentioning that this documents rather than recommends existing behavior in the abstract. (Or at least closer to the beginning of the introduction.)

[Ballot comment]
I support Stephen's DISCUSS point. My assumption in reading the recommendation is that all recursive resolvers are recommended to disable ECS by default.

= 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.

= 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.

= Section 5 =

s/client location/client network location/

= 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?

[Ballot discuss]


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" :-)

[Ballot comment]

- 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." 

- Thanks for section 2.

- 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?

- 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?

- 11.1, 4th para: "Users" isn't really right. People don't know
about any of this stuff really. "Clients" would be more accurate

1. Summary

Document Shepherd:  Suzanne Woolf
Area Director:      Joel Jaggeli

Document Type: Informational

This draft defines an EDNS0 extension to carry information about the
network that originated a DNS query, and the network for which the
subsequent response can be cached.

2. Review and Consensus

This draft originally showed up in dnsext working group and was highly criticized and eventually dropped.  Since then, dnsext closed down, the ability to get EDNS option codes because a simple expert review process and not Internet Standard, and the scope of this document was changed to document what *currently* exists in the world, and how it behaves.

There are security issues with this version, as raised by various people.  They are correct, and the intent is not to correct the security flaws with this document, but to describe how this option behaves currently.  It is suggested a new version will be worked on in a year which addresses the security issues, and addresses other issues about this option.

The extensive security writeup, several notes about privacy, and a number of implementation and operational notes included in the text were key in getting consensus support to publish the document.

3. Intellectual Property

There is no IPR related to this document, and the authors have no direct, personal knowledge of any IPR.

4. Other Points

- Downward References

There are no downward references in this document; and the shepherd agrees with the references and their classification. IDnits suggests a couple of changes; we assume they'll be made.

- IANA Considerations:

IANA has already assigned EDNS Option Code 8 for this option.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-edns-client-subnet-04.txt. If any part of this review is inaccurate, please let us know.
IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the DNS EDNS0 Option Codes (OPT) subregistry of the Domain Name System (DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters/

the following, existing registration will be made permanent and their reference will be changed to [ RFC-to-be ]:

Value: 8
Name: edns-client-subnet
Status: Optional
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Suzanne Woolf" , dnsop-chairs@ietf.org, joelja@gmail.com, suzworldwide@gmail.com, draft-ietf-dnsop-edns-client-subnet@ietf.org, dnsop@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Client Subnet in DNS Queries) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Client Subnet in DNS Queries'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft defines an EDNS0 extension to carry information about the
  network that originated a DNS query, and the network for which the
  subsequent response can be cached.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd:  Suzanne Woolf
Area Director:      Joel Jaggeli

Document Type: Informational

This draft defines an EDNS0 extension to carry information about the
network that originated a DNS query, and the network for which the
subsequent response can be cached.

2. Review and Consensus

This draft originally showed up in dnsext working group and was highly criticized and eventually dropped.  Since then, dnsext closed down, the ability to get EDNS option codes because a simple expert review process and not Internet Standard, and the scope of this document was changed to document what *currently* exists in the world, and how it behaves.

There are security issues with this version, as raised by various people.  They are correct, and the intent is not to correct the security flaws with this document, but to describe how this option behaves currently.  It is suggested a new version will be worked on in a year which addresses the security issues, and addresses other issues about this option.

3. Intellectual Property

There is no IPR related to this document, and the authors have no direct, personal knowledge of any IPR.

4. Other Points

- Downward References

There are no downward references in this document; and the shepherd agrees with the references and their classification.

- IANA Considerations:

IANA has already assigned EDNS Option Code 8 for this option.

Checklist

This section is not meant to be submitted, but is here as a useful checklist of things the document shepherd is expected to have verified before publication is requested from the responsible Area Director. If the answers to any of these is "no", please explain the situation in the body of the writeup.

X- Does the shepherd stand behind the document and think the document is ready for publication?

X- Is the correct RFC type indicated in the title page header?

X- Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

X- Is the intent of the document accurately and adequately explained in the introduction?

X- Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

X- Has the shepherd performed automated checks -- idnits (see ​http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

X- Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

X- Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

X- Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

X- If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?

X- If this is a "bis" document, have all of the errata been considered?

- IANA Considerations: