Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
draft-ietf-dnsop-refuse-any-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-11-13
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-10-15
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-10-02
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-09-20
|
07 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-09-17
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-09-17
|
07 | (System) | RFC Editor state changed to EDIT |
2018-09-17
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-09-17
|
07 | (System) | Announcement was received by RFC Editor |
2018-09-17
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-09-17
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-09-17
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-09-17
|
07 | (System) | IANA Action state changed to In Progress |
2018-09-17
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2018-09-17
|
07 | Amy Vezza | IESG has approved the document |
2018-09-17
|
07 | Amy Vezza | Closed "Approve" ballot |
2018-09-13
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-09-13
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-09-13
|
07 | Ignas Bagdonas | [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas |
2018-09-12
|
07 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-09-12
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-09-12
|
07 | Amanda Baber | IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed |
2018-09-12
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-09-12
|
07 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5482 COMMENTS S 3. > processing in order to send a conventional ANY response, and … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5482 COMMENTS S 3. > processing in order to send a conventional ANY response, and avoiding > that processing expense might be desirable. > > 3. General Approach > > This proposal provides a mechanism for an authority server to signal Nit: authoritative. S 4.3. > applications may be satisfied by this behaviour, the resulting > responses in the general case are larger than the approaches > described in Section 4.1 and Section 4.2. > > As before, if the zone is signed and the DO bit is set on the > corresponding query, an RRSIG RRSet MUST be included in the response. This section seems to be one possible algorithm for implementing 4.1. What am I missing? S 7. > It is important to note that returning a subset of available RRSets > when processing an ANY query is legitimate and consistent with > [RFC1035]; it can be argued that ANY does not always mean ALL, as > used in section 3.2.3 of [RFC1035]. The main difference here is that > the TC bit SHOULD NOT be set on the response indicating that this is > not a complete answer. This is a bit grammatically awkward, perhaps "response, thus indicating" |
2018-09-12
|
07 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-09-12
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-09-12
|
07 | Alexey Melnikov | [Ballot comment] I generally like this document, but I find it to be too wishy washy because of use of SHOULDs instead of MUSTs. I … [Ballot comment] I generally like this document, but I find it to be too wishy washy because of use of SHOULDs instead of MUSTs. I would have liked a bit more guidance early on about different choices or at least a statement that this is a rarely used feature and thus any choice is reasonably good. |
2018-09-12
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-09-12
|
07 | Terry Manderson | [Ballot comment] Thank you for the work in this document, it is clear and certainly appropriate to consider the implications of ANY in light of … [Ballot comment] Thank you for the work in this document, it is clear and certainly appropriate to consider the implications of ANY in light of operational and security concerns. |
2018-09-12
|
07 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2018-09-11
|
07 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-09-11
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-09-10
|
07 | Adam Roach | [Ballot comment] Thanks for the work that went into the mechanism, and especially to the early deployers who found issues to be addressed. I have … [Ballot comment] Thanks for the work that went into the mechanism, and especially to the early deployers who found issues to be addressed. I have a small handful of comments that the authors may wish to address prior to advancing the document to publication. --------------------------------------------------------------------------- §4.1: > A DNS responder which receives an ANY query MAY decline to provide a > conventional ANY response Nit: "A DNS responder that receives..." --------------------------------------------------------------------------- §4.2: > The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX Then, in §5: > A DNS initiator MAY suppress queries with QTYPE=ANY in the event that > the local cache contains a matching HINFO resource record with > RDATA.CPU field, as described in Section 4. This looks like it's asking for a comparison. If such is the case, I think you need to indicate whether the value being compared is done so in a case-sensitive fashion. You probably also want to be pretty explicit about the literal string value to be used (e.g., be clear that the value doesn't contain a space). --------------------------------------------------------------------------- §4.2: > The > specific value used is hence a familiar balance when choosing TTL for > any RR in any zone, and be specified according to local policy. Nit: This sentence appears to be missing a word. Perhaps "...and will be specified..." or similar. --------------------------------------------------------------------------- §4.2: > In particular, systems SHOULD NOT rely upon the HINFO > RDATA described in this seection to distinguish between synthesised > and non-synthesised HINFO RRSets. Nit: "section" More substantive comment: Since the CPU field SHOULD indicate this document, implementations could reasonably infer that the HINFO RRSet is synthesized based on its value, right? That seems worth mentioning here. --------------------------------------------------------------------------- §5: > A DNS initiator which sends a query with QTYPE=ANY and receives a Nit: "...initiator that sends..." |
2018-09-10
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-09-10
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-09-10
|
07 | Benjamin Kaduk | [Ballot comment] I am balloting YES, because it is good to have these techniques available, but I also have some comments that I would like … [Ballot comment] I am balloting YES, because it is good to have these techniques available, but I also have some comments that I would like to see addressed or rebutted. The Shepherd writeup does not say why 1034/1035 are not mentioned in the Abstract. Also, the phrase "updates [103x] by" does not appear in the Introduction, leaving just section 7 to describe the changes. The document doesn't really make it clear whether the "[t]he operator [...] might choose not to respond to such queries" is restating an existing specification from some other document or making a new statement. Section 1.1 As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719 by the time this document's publication process finishes. Section 2 It seems like the intended takeaway here is that there's a balance or tradeoff to had between the "good" uses (efficiency of getting all desired data at once) and "bad" ones (amplification), with mining for zone data being a "dual-use technology". The text doesn't really help the reader reach that conclusion, though -- a few extra words at the start of each paragraph might help, like the "legitmiately used" in the very first one, or "On the other hand, ANY queries are frequently abused to [...]" might help set the intended tone. Section 4 Should "return a conventional ANY response" be listed or mentioned here? Section 4.2 [...] The specific value used is hence a familiar balance when choosing TTL for any RR in any zone, and be specified according to local policy. nit: Is there a missing word or three before "be"? DATA described in this seection to distinguish between synthesised and non-synthesised HINFO RRSets. nit: "section" I'm a little surprised to see a "SHOULD NOT" for relying the RDATA 'CPU' contents of "RFCXXXX" for the final RFC number, since I can't come up with an other reason why that CPU value would be used. But I do not object to it. Section 4.4 Why are we enumerating transports instead of talking about the properties they provide? We've got multiple new transports in the works, and it would be a shame to ignore them out of the gate. |
2018-09-10
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-09-10
|
07 | Mirja Kühlewind | [Ballot comment] I'm wondering if it would make sense to provide stronger guidance that the conventional ANY response SHOULD be provided if TCP is used … [Ballot comment] I'm wondering if it would make sense to provide stronger guidance that the conventional ANY response SHOULD be provided if TCP is used as TCP already provides a retrun routability proof...? Also maybe provide a refernce to RFC7766? And one smallish comment: Would it make sense to refer draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC) instead of RFC7719? |
2018-09-10
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind |
2018-09-06
|
07 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2018-09-05
|
07 | Cindy Morgan | Placed on agenda for telechat - 2018-09-13 |
2018-09-05
|
07 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-09-04
|
07 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-08-30
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-08-30
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-refuse-any-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-refuse-any-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ the existing entry for: Type: * Value: 255 is to be changed by having [ RFC-to-be ] added to the references as follows: +------+-------+-------------------------------+--------------------+ | Type | Value | Meaning | Reference | +------+-------+-------------------------------+--------------------+ | * | 255 | A request for some or all | [RFC1035][RFC6895] | | | | records the server has | [This Document] | | | | available | | +------+-------+-------------------------------+--------------------+ The IANA Functions Operator 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 meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-08-23
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2018-08-23
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2018-08-23
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2018-08-23
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2018-08-22
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2018-08-22
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2018-08-21
|
07 | Warren Kumari | Removed from agenda for telechat |
2018-08-21
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-09-04): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, draft-ietf-dnsop-refuse-any@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim … The following Last Call announcement was sent out (ends 2018-09-04): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, draft-ietf-dnsop-refuse-any@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , warren@kumari.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' as Proposed Standard 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 2018-09-04. 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 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. The DNS specification does not include specific guidance for the behaviour of DNS servers or clients in this situation. This document aims to provide such guidance. This document updates RFC 1034 and RFC 1035. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-08-21
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-08-21
|
07 | Warren Kumari | Finger slipped - accidentally chose IESG Eval from drop down, not IETF LC. |
2018-08-21
|
07 | Warren Kumari | Last call was requested |
2018-08-21
|
07 | Warren Kumari | Last call announcement was generated |
2018-08-21
|
07 | Warren Kumari | IESG state changed to Last Call Requested from IESG Evaluation |
2018-08-21
|
07 | Warren Kumari | IESG state changed to IESG Evaluation from AD Evaluation::AD Followup |
2018-08-20
|
07 | Amy Vezza | Placed on agenda for telechat - 2018-08-30 |
2018-08-20
|
07 | Warren Kumari | Ballot has been issued |
2018-08-20
|
07 | Warren Kumari | Ballot approval text was generated |
2018-08-20
|
07 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2018-08-20
|
07 | Warren Kumari | Created "Approve" ballot |
2018-08-20
|
07 | Warren Kumari | Ballot writeup was changed |
2018-08-20
|
07 | Warren Kumari | Changed consensus to Yes from Unknown |
2018-08-14
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-08-14
|
07 | Joe Abley | New version available: draft-ietf-dnsop-refuse-any-07.txt |
2018-08-14
|
07 | (System) | New version approved |
2018-08-14
|
07 | (System) | Request for posting confirmation emailed to previous authors: Joe Abley , Marek Majkowski , dnsop-chairs@ietf.org, Olafur Gudmundsson |
2018-08-14
|
07 | Joe Abley | Uploaded new revision |
2018-08-14
|
06 | Warren Kumari | Authors poked: July 24th Aug 6th Aug 13th |
2018-07-21
|
06 | Warren Kumari | Sun, Jul 15, 9:33 AM - AD Review of draft-ietf-dnsop-refuse-any |
2018-07-21
|
06 | Warren Kumari | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2018-07-06
|
06 | Tim Wicinski | Tag Doc Shepherd Follow-up Underway cleared. |
2018-07-06
|
06 | Tim Wicinski | refuse-any (1) This documet is being presented as a Proposed Standard. It is stated in the title page and it is the proper type of … refuse-any (1) This documet is being presented as a Proposed Standard. It is stated in the title page and it is the proper type of RFC. (2) Technical Summary: The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. This document provides specific behaviorial guidance for DNS servers and/or clients. Working Group Summary There was some initial issues reaching consensus during WGLC, but the authors worked out the specific issues with the working group and the final version met with strong consensus. Document Quality Document has been well written and edited. There are current implementaions that help drive consensus. Personnel Document Shepherd is Tim Wicinski and Area Director is Warren Kumari. (3) The document shepherd did several thorough reviews of this document, both for content as well as editing issues. (4) The document shepherd is more than satisfied with the depth and breath of the reviews. (5) It is the opinion of the document shepherd that this document does not need broader reviews. (6) The document shepherd has no specific concerns or issues with this document. (7) The authors have confirmed that there are no IPR disclosures that need to be filed. (8) No IPR disclosures have been filed for this document. (9) WG Consensus is solid. (10) There has been no threats to appeal or discontent. (11) -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to mention this, which it should. Found 'SHOULD not' in this paragraph: It is important to note that returning a subset of available RRSets when processing an ANY query is legitimate and consistent with [RFC1035]; it can be argued that ANY does not always mean ALL, as used in section 3.2.3 of [RFC1035]. The main difference here is that the TC bit SHOULD not be set on the response indicating that this is not a complete answer. (12) Document does not meet any required formal review criteria. (13) All references have been identified as either normative or informative. (14) There are not normative references that are holding up this document. (15) There are no downward normative references in this document. (16) This document will update RFC 1034 and RFC 1035. These RFCs are listed int the title page, discussed in the introduction. These RFCs are not mentioned in the abstract. (17) The IANA considerations section requests an update to the Resource Record (RR) Types Registry to reference this document for one value. This is consistent with the body of the document. (18) There are no new IANA registries. |
2018-07-06
|
06 | Tim Wicinski | Responsible AD changed to Warren Kumari |
2018-07-06
|
06 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-07-06
|
06 | Tim Wicinski | IESG state changed to Publication Requested |
2018-07-06
|
06 | Tim Wicinski | IESG process started in state Publication Requested |
2018-07-06
|
06 | Tim Wicinski | Changed document writeup |
2018-03-05
|
06 | Joe Abley | New version available: draft-ietf-dnsop-refuse-any-06.txt |
2018-03-05
|
06 | (System) | New version approved |
2018-03-05
|
06 | (System) | Request for posting confirmation emailed to previous authors: Joe Abley , Marek Majkowski , Olafur Gudmundsson |
2018-03-05
|
06 | Joe Abley | Uploaded new revision |
2018-03-05
|
05 | Joe Abley | New version available: draft-ietf-dnsop-refuse-any-05.txt |
2018-03-05
|
05 | (System) | New version approved |
2018-03-05
|
05 | (System) | Request for posting confirmation emailed to previous authors: dnsop-chairs@ietf.org, Marek Majkowski , Joe Abley , Olafur Gudmundsson |
2018-03-05
|
05 | Joe Abley | Uploaded new revision |
2017-08-12
|
04 | (System) | Document has expired |
2017-03-16
|
04 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Consensus: Waiting for Write-Up |
2017-03-09
|
04 | Tim Wicinski | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2017-02-08
|
04 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-refuse-any-04.txt |
2017-02-08
|
04 | (System) | New version approved |
2017-02-08
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Marek Majkowski" , "Olafur Gudmundsson" , "Joe Abley" |
2017-02-08
|
04 | Ólafur Guðmundsson | Uploaded new revision |
2016-12-30
|
03 | Tim Wicinski | Tag Revised I-D Needed - Issue raised by WGLC set. |
2016-12-30
|
03 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2016-11-25
|
03 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2016-11-15
|
03 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-refuse-any-03.txt |
2016-11-15
|
03 | (System) | New version approved |
2016-11-15
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Joe Abley" , "Marek Majkowski" , dnsop-chairs@ietf.org, "Olafur Gudmundsson" |
2016-11-15
|
03 | Ólafur Guðmundsson | Uploaded new revision |
2016-07-25
|
02 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-refuse-any-02.txt |
2016-04-06
|
01 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-refuse-any-01.txt |
2015-12-15
|
00 | Tim Wicinski | Intended Status changed to Proposed Standard from Internet Standard |
2015-12-15
|
00 | Tim Wicinski | Intended Status changed to Proposed Standard from Internet Standard |
2015-11-28
|
00 | Tim Wicinski | Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com> |
2015-11-28
|
00 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2015-11-28
|
00 | Tim Wicinski | Intended Status changed to Internet Standard from None |
2015-11-05
|
00 | Tim Wicinski | This document now replaces draft-dnsop-refuse-any instead of None |
2015-11-05
|
00 | Joe Abley | New version available: draft-ietf-dnsop-refuse-any-00.txt |