Skip to main content

Client Subnet in DNS Queries
RFC 7871

Revision differences

Document history

Date Rev. By Action
2020-01-21
08 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2016-05-20
08 (System) RFC published
2016-05-17
08 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7871">AUTH48-DONE</a> from AUTH48
2016-05-12
08 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7871">AUTH48</a> from RFC-EDITOR
2016-05-04
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-04-25
08 (System) RFC Editor state changed to EDIT from AUTH
2016-04-20
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-04-19
08 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2016-04-19
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2016-04-19
08 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-08.txt
2016-04-13
07 (System) RFC Editor state changed to AUTH from EDIT
2016-03-30
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-03-30
07 (System) RFC Editor state changed to EDIT
2016-03-30
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-03-30
07 (System) Announcement was received by RFC Editor
2016-03-28
07 (System) IANA Action state changed to In Progress
2016-03-28
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2016-03-28
07 Amy Vezza IESG has approved the document
2016-03-28
07 Amy Vezza Closed "Approve" ballot
2016-03-28
07 Amy Vezza Ballot approval text was generated
2016-03-27
07 Joel Jaeggli IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2016-03-21
07 Stephen Farrell
[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 …
[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
2016-03-21
07 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2016-03-21
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-03-21
07 Warren Kumari IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-03-21
07 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-07.txt
2016-02-22
06 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2016-01-28
06 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2016-01-25
06 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2016-01-21
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2016-01-21
06 Cindy Morgan Changed consensus to Yes from Unknown
2016-01-21
06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-01-21
06 Jari Arkko
[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 …
[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.
2016-01-21
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-01-20
06 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2016-01-20
06 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2016-01-20
06 Ben Campbell
[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 …
[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.)
2016-01-20
06 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-01-20
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-01-20
06 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-01-20
06 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-01-20
06 Alissa Cooper
[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. …
[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?
2016-01-20
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-01-20
06 Stephen Farrell
[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 …
[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" :-)
2016-01-20
06 Stephen Farrell
[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 …
[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
2016-01-20
06 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2016-01-19
06 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2016-01-18
06 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-01-18
06 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-01-14
06 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2016-01-14
06 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2016-01-04
06 Joel Jaeggli Placed on agenda for telechat - 2016-01-21
2016-01-04
06 Joel Jaeggli IESG state changed to IESG Evaluation from Waiting for Writeup
2016-01-04
06 Joel Jaeggli Ballot has been issued
2016-01-04
06 Joel Jaeggli [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli
2016-01-04
06 Joel Jaeggli Created "Approve" ballot
2016-01-04
06 Joel Jaeggli Ballot writeup was changed
2015-12-30
06 Suzanne Woolf
1. Summary

Document Shepherd:  Suzanne Woolf
Area Director:      Joel Jaggeli

Document Type: Informational

This draft defines an EDNS0 extension to carry information about …
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.
2015-12-21
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-12-15
06 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2015-12-15
06 Sabrina Tanamal
(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 …
(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
2015-12-15
06 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-06.txt
2015-12-14
05 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-05.txt
2015-12-12
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2015-12-12
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2015-12-10
04 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2015-12-10
04 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2015-12-10
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2015-12-10
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2015-12-07
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-12-07
04 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: "Suzanne Woolf" <suzworldwide@gmail.com>, dnsop-chairs@ietf.org …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: "Suzanne Woolf" <suzworldwide@gmail.com>, 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: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-dnsop-edns-client-subnet-04.txt> (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'
  <draft-ietf-dnsop-edns-client-subnet-04.txt> 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.


2015-12-07
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-12-07
04 Joel Jaeggli Last call was requested
2015-12-07
04 Joel Jaeggli Last call announcement was generated
2015-12-07
04 Joel Jaeggli Ballot approval text was generated
2015-12-07
04 Joel Jaeggli Ballot writeup was generated
2015-12-07
04 Joel Jaeggli IESG state changed to Last Call Requested from AD Evaluation
2015-11-15
04 Joel Jaeggli IESG state changed to AD Evaluation from Publication Requested
2015-11-13
04 Tim Wicinski
1. Summary

Document Shepherd:  Suzanne Woolf
Area Director:      Joel Jaggeli

Document Type: Informational

This draft defines an EDNS0 extension to carry information about …
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:
2015-11-13
04 Tim Wicinski Responsible AD changed to Joel Jaeggli
2015-11-13
04 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2015-11-13
04 Tim Wicinski IESG state changed to Publication Requested
2015-11-13
04 Tim Wicinski IESG process started in state Publication Requested
2015-11-13
04 Tim Wicinski Changed document writeup
2015-11-03
04 Tim Wicinski Changed document writeup
2015-11-03
04 Suzanne Woolf Notification list changed to "Suzanne Woolf" <suzworldwide@gmail.com>
2015-11-03
04 Suzanne Woolf Document shepherd changed to Suzanne Woolf
2015-10-09
04 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2015-09-25
04 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-04.txt
2015-08-24
03 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-03.txt
2015-07-06
02 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-02.txt
2015-06-22
01 Tim Wicinski Intended Status changed to Informational from None
2015-05-26
01 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-01.txt
2014-11-15
00 Tim Wicinski This document now replaces draft-vandergaast-edns-client-subnet instead of None
2014-11-15
00 Warren Kumari New version available: draft-ietf-dnsop-edns-client-subnet-00.txt