Serving Stale Data to Improve DNS Resiliency
draft-ietf-dnsop-serve-stale-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-03-30
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-03-23
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-02-11
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-12-13
|
10 | (System) | RFC Editor state changed to EDIT |
2019-12-13
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-12-13
|
10 | (System) | Announcement was received by RFC Editor |
2019-12-12
|
10 | (System) | IANA Action state changed to In Progress |
2019-12-12
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-12-12
|
10 | Cindy Morgan | IESG has approved the document |
2019-12-12
|
10 | Cindy Morgan | Closed "Approve" ballot |
2019-12-12
|
10 | Cindy Morgan | Ballot approval text was generated |
2019-12-12
|
10 | Barry Leiba | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-12-09
|
10 | David Lawrence | New version available: draft-ietf-dnsop-serve-stale-10.txt |
2019-12-09
|
10 | (System) | New version accepted (logged-in submitter: David Lawrence) |
2019-12-09
|
10 | David Lawrence | Uploaded new revision |
2019-12-05
|
09 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2019-12-05
|
09 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-12-04
|
09 | Benjamin Kaduk | [Ballot comment] Thanks for this document; it's some good comprehensive discussion of the issues related to this topic and will improve the stability of the … [Ballot comment] Thanks for this document; it's some good comprehensive discussion of the issues related to this topic and will improve the stability of the internet. I have several minor coments and a few side notes that are expected to lead to at most my own elucidiation (but no textual changes). Section 2 For a comprehensive treatment of DNS terms, please see [RFC8499]. (side note: I myself would not use the word "comprehensive" when it explicitly says that "some DNS-related terms are interpreted quite differently by different DNS experts", but I understand why it is used here.) Section 3 There are a number of reasons why an authoritative server may become unreachable, including Denial of Service (DoS) attacks, network issues, and so on. If a recursive server is unable to contact the authoritative servers for a query but still has relevant data that side note: the way this is worded might make a reader wonder if the recursive is expected to attempt to contact all known authoritatives before declaring failure. Several recursive resolver operators, including Akamai, currently use stale data for answers in some way. A number of recursive resolver I did not follow the discussions that led to this wording, but one of my colleagues at Akamai suggested that "currently fall back to stale data for answers under some circumstances" might be a nicer wording, though I note that Adam has already proposed some text here as well, which is probably fine. Section 4 The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is amended to read: TTL a 32-bit unsigned integer number of seconds that specifies the duration that the resource record MAY be cached before the source of the information MUST again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. Values SHOULD be capped on the orders of days to weeks, with a recommended cap of 604,800 seconds (seven days). If the data is unable to be authoritatively refreshed when the TTL expires, the record MAY be used as though it is unexpired. See the Section 5 and Section 6 sections for details. I recommend using "[this document]" in the section references, since a reader reading the updated content in the context of RFC 1035 might look there instead of here. Section 5 The resolver then checks its cache for any unexpired records that satisfy the request and returns them if available. If it finds no relevant unexpired data and the Recursion Desired flag is not set in the request, it should immediately return the response without consulting the cache for expired records. Typically this response would be a referral to authoritative nameservers covering the zone, but the specifics are implementation-dependent. side note: I'm slightly surprised that the semantics of the absence of Recusion Desired are not more tightly nailed down, but neither is it the role of this document to specify them. When no authorities are able to be reached during a resolution attempt, the resolver should attempt to refresh the delegation and restart the iterative lookup process with the remaining time on the query resolution timer. This resumption should be done only once during one resolution effort. Is the "during one" more like a global cap or more like "during a given"? Section 6 The client response timer is another variable which deserves consideration. If this value is too short, there exists the risk that stale answers may be used even when the authoritative server is actually reachable but slow; this may result in sub-optimal answers being returned. Conversely, waiting too long will negatively impact user experience. Not just sub-optimal but potentially even wrong or actively harmful answers, no? The balance for the failure recheck timer is responsiveness in detecting the renewed availability of authorities versus the extra resource use for resolution. If this variable is set too large, stale answers may continue to be returned even after the authoritative server is reachable; per [RFC2308], Section 7, this should be no more than five minutes. If this variable is too small, authoritative servers may be rapidly hit with a significant amount of traffic when they become reachable again. I think part of the concern is also that setting the value too small will cause additional traffic towards the authoritative even while it is nonresponsive/nonreachable, which could aggravate any DoS attack ongoing against the authoritative. Which is to say, that perhaps "became reachable again" does not quite reflect the full set of considerations. Regarding the TTL to set on stale records in the response, historically TTLs of zero seconds have been problematic for some implementations, and negative values can't effectively be communicated to existing software. Other very short TTLs could lead to congestive collapse as TTL-respecting clients rapidly try to refresh. The recommended value of 30 seconds not only sidesteps those potential problems with no practical negative consequences, it also rate limits further queries from any client that honors the TTL, such as a forwarding resolver. I a little-bit wonder whether an RFC 8085 reference would make sense here, but that's not exactly my area of expertise. There's also no record of TTLs in the wild having the most significant bit set in DNS-OARC's "Day in the Life" samples. With no Should we have a reference for DNS-OARC's samples? apparent reason for operators to use them intentionally, that leaves either errors or non-standard experiments as explanations as to why such TTLs might be encountered, with neither providing an obviously compelling reason as to why having the leading bit set should be treated differently from having any of the next eleven bits set and then capped per Section 4. side note(?): This discussion, as roughly "we can't think of any reason why the change would be problematic", calls to mind the ongoing discussions of RFC (text) format changes, where arguments are being made for more-strict backwards/historical compatibility. That said, I have no reason to doubt the WG consensus position here, hence "side note". Section 7 Be aware that Canonical Name (CNAME) and DNAME [RFC6672] records mingled in the expired cache with other records at the same owner name can cause surprising results. This was observed with an initial implementation in BIND when a hostname changed from having an IPv4 Address (A) record to a CNAME. The version of BIND being used did not evict other types in the cache when a CNAME was received, which in normal operations is not a significant issue. However, after both records expired and the authorities became unavailable, the fallback to stale answers returned the older A instead of the newer CNAME. I'm not sure to what extent the lesson from this scenario is limited to "CNAME/DNAME are special" versus "when serving stale, serve the least-stale you have". Section 8 Details of Apple's implementation are not currently known. I'm amenable to the other reviewer's comment that this section might be interesting to keep, RFC 6982 notwithstanding, in which case this might be more appropriately worded as "publicly disclosed" -- one assumes that the Apple employees that wrote it know what it does! Section 10 The most obvious security issue is the increased likelihood of DNSSEC validation failures when using stale data because signatures could be returned outside their validity period. Stale negative records can We seem to be carefully not giving explicit guidance about using "stale" DNSSEC keys in addition to stale resolution records. If the consequences of potentially using expired key material are more severe than the consequences of potentially using expired DNS records (as it seems to me), perhaps we should explicitly reiterate that serve-stale is not an excuse to ignore key validity periods (as we are implicitly doing here)? In [CloudStrife], it was demonstrated how stale DNS data, namely hostnames pointing to addresses that are no longer in use by the owner of the name, can be used to co-opt security such as to get domain-validated certificates fraudulently issued to an attacker. While this document does not create a new vulnerability in this area, it does potentially enlarge the window in which such an attack could be made. A proposed mitigation is that certificate authorities should fully look up each name starting at the DNS root for every name lookup. Alternatively, CAs should use a resolver that is not serving stale data. [I think Adam has probably already covered this one, but keeping just in case.] I note that the target of this guidance (CAs) is not obviously in the expected readership set for a document about DNS recursive resolver operational considerations. Can we do more to expand the visibility of this guidance to the audience where it would be most useful? (I don't see an obvious candidate for, e.g., an additional Updates: relationship, but perhaps someone has other ideas.) |
2019-12-04
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-12-04
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-12-04
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-12-04
|
09 | Suresh Krishnan | [Ballot comment] * Section 6 It might be useful to include a reference to DITL for some background on the dataset mentioned in this section … [Ballot comment] * Section 6 It might be useful to include a reference to DITL for some background on the dataset mentioned in this section http://www.caida.org/projects/ditl/ |
2019-12-04
|
09 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2019-12-04
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-12-03
|
09 | Roman Danyliw | [Ballot comment] * I agree with Mirja, Section 8 is more informative than what is alluded to the paragraph starting with “Several recursive resolvers …” … [Ballot comment] * I agree with Mirja, Section 8 is more informative than what is alluded to the paragraph starting with “Several recursive resolvers …” in Section 3, and IMO is worth keeping. I struck me as odd to call out the operation practice of a particular vendor (Akamai). We might want to check if this reference is ok – Ben? * A few reference nits: - Section 6. Per the mention to DNS-OARC, please provide a citation. - Section 6 and 9. The text references “during discussions in the IETF”. What is that specifically – WG deliberation? * Thanks for covering the attacker use cases of stale data in Section 10. |
2019-12-03
|
09 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2019-12-03
|
09 | Roman Danyliw | [Ballot comment] * I agree with Mirja, Section 8 is more informative than what is alluded to the paragraph starting with “Several recursive resolvers …” … [Ballot comment] * I agree with Mirja, Section 8 is more informative than what is alluded to the paragraph starting with “Several recursive resolvers …” in Section 3, and IMO is worth keeping. I struck me as odd to call out the operation practice of a particular vendor (Akamai). We might want to check if this reference is ok – Ben? * A few reference nits: - Section 6. Per the mention to DNS-OARC, please provide a citation. - Section 6 and 9. The text references “during discussions in the IETF”. What is that specifically – WG deliberation? * Thanks for covering how the attacker use cases of stale data in Section 10. |
2019-12-03
|
09 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-12-02
|
09 | Adam Roach | [Ballot comment] Thanks to everyone who put work into documenting this useful and apparently well-deployed mechanism. I have a handful of comments on the current … [Ballot comment] Thanks to everyone who put work into documenting this useful and apparently well-deployed mechanism. I have a handful of comments on the current document. --------------------------------------------------------------------------- §3: > Several recursive resolver operators, including Akamai, currently use > stale data for answers in some way. This won't age well; and it's not clear why calling out Akamai amongst the various DNS service providers is warranted. Suggest: At the time of this document's publication, several recursive resolver operators use stale data for answers in some way (If the notion of citing Akamai is to indicate the scale of such operators, I suggest "...operators, including large-scale operators, use stale...") --------------------------------------------------------------------------- §4: > The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is > amended to read: > > TTL a 32-bit unsigned integer number of seconds that specifies the > duration that the resource record MAY be cached before the source > of the information MUST again be consulted. Zero values are > interpreted to mean that the RR can only be used for the > transaction in progress, and should not be cached. Values SHOULD > be capped on the orders of days to weeks, with a recommended cap > of 604,800 seconds (seven days). If the data is unable to be > authoritatively refreshed when the TTL expires, the record MAY be > used as though it is unexpired. See the Section 5 and Section 6 > sections for details. The addition of what I must presume is intended to be RFC 2119 language to a document that doesn't cite RFC 2119 seems questionable. I would suggest either explicitly adding RFC 2119 boilerplate to RFC 1035 as part of this update, or using plain English language to convey the same concepts as are intended. Nit: "See the Section 5 and Section 6 sections for details" is a very awkward way to phrase the closing sentence. More substantively: Sections 5 and 6 of RFC 1035 are "MASTER FILES" and "NAME SERVER IMPLEMENTATION" respectively. Is this final sentence intended to refer to those two sections? Or is it pointing to "Example Method" and "Implementation Considerations" of this document? If the latter, please specifically cite this document (e.g., "See Section 5 and Section 6 of [RFCXXXX] for details.") --------------------------------------------------------------------------- §4: > therefor leave any previous state intact. See Section 6 for a Nit: "therefore" --------------------------------------------------------------------------- §5: > When a request is received by a recursive resolver, it should start > the client response timer. The passive tense in this sentence makes "it" linguistically ambiguous. Suggest: "When the recursive resolver receives a request, it should start..." --------------------------------------------------------------------------- §10: > A proposed mitigation is that certificate authorities > should fully look up each name starting at the DNS root for every > name lookup. Alternatively, CAs should use a resolver that is not > serving stale data. This seems like a perfectly good solution, although I wonder how many CAs are likely to read this document. If I were the type to engage in wagering, I'd put all of my money on "zero." I'm not sure specific action is called for prior to publication of this document as an RFC, but it seems that additional publicity of this issue and the way that serve-stale interacts with it -- e.g., to CAB Forum and its members -- is warranted. |
2019-12-02
|
09 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-12-02
|
09 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-12-02
|
09 | Mirja Kühlewind | [Ballot comment] Two comments: 1) It seems to me that this sentence in section 7 should/could actually be phrased as a normative requirement in this … [Ballot comment] Two comments: 1) It seems to me that this sentence in section 7 should/could actually be phrased as a normative requirement in this document: "it is not necessary that every client request needs to trigger a new lookup flow in the presence of stale data, but rather that a good-faith effort has been recently made to refresh the stale data before it is delivered to any client." Maybe worth considering... 2) I find the Implementation Status section (8) actually quite interesting for this document and maybe it should be considered to keep it in the document for final publication. |
2019-12-02
|
09 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-12-01
|
09 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. The short document is easy to read. Feel free to ignore the sentences below. … [Ballot comment] Thank you for the work put into this document. The short document is easy to read. Feel free to ignore the sentences below. I loved the sentence "stale bread is better than no bread.", who said that I-D are boring? :-) Should the assertion about DNS stale data by products (end of section 3) be documented by external documents? Somehow addressed in section 8 (to be removed...) Finally, I am unsure whether it is worth documenting the WG discussion about EDNS. Regards, -éric |
2019-12-01
|
09 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-11-29
|
09 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2019-11-20
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2019-11-20
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2019-11-18
|
09 | Warren Kumari | [Ballot comment] Recusing because I'm an author. |
2019-11-18
|
09 | Warren Kumari | [Ballot Position Update] New position, Recuse, has been recorded for Warren Kumari |
2019-11-18
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2019-11-18
|
09 | Cindy Morgan | Placed on agenda for telechat - 2019-12-05 |
2019-11-18
|
09 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::Point Raised - writeup needed |
2019-11-18
|
09 | Barry Leiba | Ballot has been issued |
2019-11-18
|
09 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2019-11-18
|
09 | Barry Leiba | Created "Approve" ballot |
2019-11-18
|
09 | Barry Leiba | Ballot writeup was changed |
2019-10-24
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-10-24
|
09 | David Lawrence | New version available: draft-ietf-dnsop-serve-stale-09.txt |
2019-10-24
|
09 | (System) | New version accepted (logged-in submitter: David Lawrence) |
2019-10-24
|
09 | David Lawrence | Uploaded new revision |
2019-10-18
|
08 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Joel Jaeggli was marked no-response |
2019-09-25
|
08 | Barry Leiba | IESG state changed to Waiting for AD Go-Ahead::Point Raised - writeup needed from Waiting for Writeup |
2019-09-25
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-09-24
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-09-24
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dnsop-serve-stale-07, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dnsop-serve-stale-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-09-23
|
08 | Adam Montville | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Adam Montville. Sent review to list. |
2019-09-19
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-09-19
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-09-18
|
08 | Puneet Sood | New version available: draft-ietf-dnsop-serve-stale-08.txt |
2019-09-18
|
08 | (System) | New version approved |
2019-09-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: Puneet Sood , Warren Kumari , David Lawrence |
2019-09-18
|
08 | Puneet Sood | Uploaded new revision |
2019-09-16
|
07 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list. |
2019-09-12
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2019-09-12
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2019-09-12
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2019-09-12
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2019-09-11
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-09-11
|
07 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-09-25): From: The IESG To: IETF-Announce CC: dnsop-chairs@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne … The following Last Call announcement was sent out (ends 2019-09-25): From: The IESG To: IETF-Announce CC: dnsop-chairs@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , barryleiba@gmail.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Serving Stale Data to Improve DNS Resiliency' 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 2019-09-25. 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 a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks, and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFC 1034 and RFC 1035 so that data can be kept in the cache beyond the TTL expiry, and also updates RFC 2181 by interpreting values with the high order bit set as being positive, rather than 0, and also suggests a cap of 7 days. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3589/ https://datatracker.ietf.org/ipr/3014/ https://datatracker.ietf.org/ipr/3590/ https://datatracker.ietf.org/ipr/3059/ https://datatracker.ietf.org/ipr/3573/ https://datatracker.ietf.org/ipr/2967/ https://datatracker.ietf.org/ipr/2968/ |
2019-09-11
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-09-11
|
07 | Barry Leiba | Last call was requested |
2019-09-11
|
07 | Barry Leiba | Last call announcement was generated |
2019-09-11
|
07 | Barry Leiba | Ballot approval text was generated |
2019-09-11
|
07 | Barry Leiba | Ballot writeup was generated |
2019-09-11
|
07 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation |
2019-09-11
|
07 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2019-08-30
|
07 | Warren Kumari | New version available: draft-ietf-dnsop-serve-stale-07.txt |
2019-08-30
|
07 | (System) | New version approved |
2019-08-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: Puneet Sood , Warren Kumari , David Lawrence |
2019-08-30
|
07 | Warren Kumari | Uploaded new revision |
2019-08-28
|
06 | Amy Vezza | Shepherding AD changed to Barry Leiba |
2019-08-27
|
06 | Suzanne Woolf | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. It updates the definition of TTL in RFC 1034, 1035, and 2181. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. It updates the definition of TTL from RFCs 1034, 1035, and 2181 to make it clear that data can be kept in the cache beyond the TTL expiry and used for responses when a refreshed answer is not readily available. (From the Abstract.) Working Group Summary This draft dates to March 2017 and was adopted by DNSOP in October 2017. It's been extensively reviewed in the WG. The primary point of controversy was that it discusses an optional protocol change (the choice by a recursive resolver to re-use data beyond the authoritative server TTL when no refresh is available) that some WG participants felt to be unwise under some conditions. The discussion of timer values in Sec. 5, and of implementation decisions and caveats in Sec. 6 and Sec. 7, seem to address these concerns. Since this protocol modification is widely implemented and deployed, having a standards track description seemed to promote careful practice and interoperability. Document Quality The protocol update discussed in this draft is an attempt to document behavior that is implemented in multiple open source DNS codebases and deployed by a number of large operators, including DNS services and CDNs that rely on the specified DNS behavior. Common practice regarding the handling of TTLs by recursive resolvers has changed considerably over the behavior originally specified, and documenting the current practice as an update to the protocol seems likely to promote interoperability and transparency under both normal and adverse conditions. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Suzanne Woolf (shepherd) Barry Leiba (AD; the WG's AD, Warren Kumari, is an author.) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. There are some minor issues (typos, minor copyedits) but this document is ready for IESG review. (-07) (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The WG core of participants are exactly the people to review this, based on protocol knowledge, implementation experience, and operational experience. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. From time to time, DNSOP considers documents that describe DNS behavior that might be controversial, or whose costs and benefits are not universally agreed on. In those situations, sometimes the WG has to decide whether they feel that the documented behavior is harmful, and if so whether documenting it encourages or limits the harm. Some discussion along those lines occurred around this document. The chairs believe the concerns were addressed and there is consensus to advance the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. All authors have confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are several IPR disclosures. In all three cases of specific disclosures, the companies responsible have affirmed they're granting licenses for any use of their technology in the implementation of this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document seems to be supported by multiple implementers and operators as reflecting current or planned practice, with the benefits and caveats described. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a number of update_references warnings from idnits. Some are hard to parse (they flag external references e.g. [DikeBreaks]). Many are due to the extensive discussion of changes in meaning of terms now considered RFC2119-normative as used in a much older RFC (1034). The warning about an improper URL is spurious (it's a live URL, not an example, and it's in an "Implementation Experience" section that will be removed prior to publication.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFCs 1034, 1035, and 2181. The shepherd believes the intended effect is clear. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are no actions for IANA in this document, and it has no impact on the meaning of any existing IANA registry or allocated codepoint. It updates the use of a field in DNS RRs as defined in the original specification but requires no change to that definition. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2019-08-27
|
06 | Suzanne Woolf | Responsible AD changed to Warren Kumari |
2019-08-27
|
06 | Suzanne Woolf | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-08-27
|
06 | Suzanne Woolf | IESG state changed to Publication Requested from I-D Exists |
2019-08-27
|
06 | Suzanne Woolf | IESG process started in state Publication Requested |
2019-08-27
|
06 | Suzanne Woolf | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. It updates the definition of TTL in RFC 1034, 1035, and 2181. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. It updates the definition of TTL from RFCs 1034, 1035, and 2181 to make it clear that data can be kept in the cache beyond the TTL expiry and used for responses when a refreshed answer is not readily available. (From the Abstract.) Working Group Summary This draft dates to March 2017 and was adopted by DNSOP in October 2017. It's been extensively reviewed in the WG. The primary point of controversy was that it discusses an optional protocol change (the choice by a recursive resolver to re-use data beyond the authoritative server TTL when no refresh is available) that some WG participants felt to be unwise under some conditions. The discussion of timer values in Sec. 5, and of implementation decisions and caveats in Sec. 6 and Sec. 7, seem to address these concerns. Since this protocol modification is widely implemented and deployed, having a standards track description seemed to promote careful practice and interoperability. Document Quality The protocol update discussed in this draft is an attempt to document behavior that is implemented in multiple open source DNS codebases and deployed by a number of large operators, including DNS services and CDNs that rely on the specified DNS behavior. Common practice regarding the handling of TTLs by recursive resolvers has changed considerably over the behavior originally specified, and documenting the current practice as an update to the protocol seems likely to promote interoperability and transparency under both normal and adverse conditions. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Suzanne Woolf (shepherd) Barry Leiba (AD; the WG's AD, Warren Kumari, is an author.) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. There are some minor issues (typos, minor copyedits) but this document is ready for IESG review. (-07) (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The WG core of participants are exactly the people to review this, based on protocol knowledge, implementation experience, and operational experience. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. From time to time, DNSOP considers documents that describe DNS behavior that might be controversial, or whose costs and benefits are not universally agreed on. In those situations, sometimes the WG has to decide whether they feel that the documented behavior is harmful, and if so whether documenting it encourages or limits the harm. Some discussion along those lines occurred around this document. The chairs believe the concerns were addressed and there is consensus to advance the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. All authors have confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are several IPR disclosures. In all three cases of specific disclosures, the companies responsible have affirmed they're granting licenses for any use of their technology in the implementation of this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document seems to be supported by multiple implementers and operators as reflecting current or planned practice, with the benefits and caveats described. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a number of update_references warnings from idnits. Some are hard to parse (they flag external references e.g. [DikeBreaks]). Many are due to the extensive discussion of changes in meaning of terms now considered RFC2119-normative as used in a much older RFC (1034). The warning about an improper URL is spurious (it's a live URL, not an example, and it's in an "Implementation Experience" section that will be removed prior to publication.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFCs 1034, 1035, and 2181. The shepherd believes the intended effect is clear. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are no actions for IANA in this document, and it has no impact on the meaning of any existing IANA registry or allocated codepoint. It updates the use of a field in DNS RRs as defined in the original specification but requires no change to that definition. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2019-08-26
|
06 | Suzanne Woolf | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. It updates the definition of TTL in RFC 1034, 1035, and 2181. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. It updates the definition of TTL from [RFC1034], [RFC1035], and [RFC2181] to make it clear that data can be kept in the cache beyond the TTL expiry and used for responses when a refreshed answer is not readily available. (From the Abstract.) Working Group Summary This draft dates to March 2017 and was adopted by DNSOP in October 2017. It's been extensively reviewed in the WG. The primary point of controversy was that it discusses an optional protocol change (the choice by a recursive resolver to re-use data beyond the authoritative server TTL when no refresh is available) that some WG participants felt to be unwise under some conditions. The discussion of timer values in Sec. 5, and of implementation decisions and caveats in Sec. 6 and Sec. 7, seem to address these concerns. Since this protocol modification is widely implemented and deployed, having a standards track description seemed to promote careful practice and interoperability. Document Quality The protocol update discussed in this draft is an attempt to document behavior that is implemented in multiple open source DNS codebases and deployed by a number of large operators, including DNS services and CDNs that rely on the specified DNS behavior. Common practice regarding the handling of TTLs by recursive resolvers has changed considerably over the behavior originally specified, and documenting the current practice as an update to the protocol seems likely to promote interoperability and transparency under both normal and adverse conditions. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Suzanne Woolf (shepherd) Barry Leiba (AD; the WG's AD, Warren Kumari, is an author.) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. There are some minor issues (typos, minor copyedits) but this document is ready for IESG review. (-07) (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The WG core of participants are exactly the people to review this, based on protocol knowledge, implementation experience, and operational experience. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. From time to time, DNSOP considers documents that describe DNS behavior that might be controversial, or whose costs and benefits are not universally agreed on. In those situations, sometimes the WG has to decide whether they feel that the documented behavior is harmful, and if so whether documenting it encourages or limits the harm. Some discussion along those lines occurred around this document. The chairs believe the concerns were addressed and there is consensus to advance the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. (*** waiting for confirmation) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are several IPR disclosures. In all three cases of specific disclosures, the companies responsible have affirmed they're granting licenses for any use of their technology in the implementation of this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document seems to be supported by multiple implementers and operators as reflecting current or planned practice, with the benefits and caveats described. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a number of update_references warnings from idnits. Some are hard to parse (they flag external references e.g. [DikeBreaks]). Many are due to the extensive discussion of changes in meaning of terms now considered RFC2119-normative as used in a much older RFC (1034). The warning about an improper URL is spurious (it's a live URL, not an example, and it's in an "Implementation Experience" section that will be removed prior to publication.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC1034, 1035, and 2181. The shepherd believes the intended effect is clear. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are no actions for IANA in this document, and it has no impact on the meaning of any existing IANA registry or allocated codepoint. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2019-08-26
|
06 | Suzanne Woolf | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. It updates the definition of TTL in RFC 1034 and 1035. (*** This needs to be fixed for -07.) (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: (*** authors please review) Technical Summary This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. It updates the definition of TTL from [RFC1034], [RFC1035], and [RFC2181] to make it clear that data can be kept in the cache beyond the TTL expiry and used for responses when a refreshed answer is not readily available. (From the Abstract.) Working Group Summary This draft dates to March 2017 and was adopted by DNSOP in October 2017. It's been extensively reviewed in the WG. The primary point of controversy was that it discusses an optional protocol change (the choice by a recursive resolver to re-use data beyond the authoritative server TTL when no refresh is available) that some WG participants felt to be unwise under some conditions. The discussion of timer values in Sec. 5, and of implementation decisions and caveats in Sec. 6 and Sec. 7, seem to address these concerns. Since this protocol modification is widely implemented and deployed, having a standards track description seemed to promote careful practice and interoperability. Document Quality The protocol update discussed in this draft is an attempt to document behavior that is implemented in multiple open source DNS codebases and deployed by a number of large operators, including DNS services and CDNs that rely on the specified DNS behavior. Common practice regarding the handling of TTLs by recursive resolvers has changed considerably over the behavior originally specified, and documenting the current practice as an update to the protocol seems likely to promote interoperability and transparency under both normal and adverse conditions. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Suzanne Woolf (shepherd) Ignas Bagdonas (AD; the WG's AD, Warren Kumari, is an author.) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. There are some minor issues (typos, a reference that needs to be updated) but this document is ready for IESG review. (-06) (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The WG core of participants are exactly the people to review this, based on protocol knowledge, implementation experience, and operational experience. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. From time to time, DNSOP considers documents that describe DNS behavior that might be controversial, or whose costs and benefits are not universally agreed on. In those situations, sometimes the WG has to decide whether they feel that the documented behavior is harmful, and if so whether documenting it encourages or limits the harm. Some discussion along those lines occurred around this document. The chairs believe the concerns were addressed and there is consensus to advance the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. (*** waiting for confirmation) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are several IPR disclosures. In all three cases of specific disclosures, the companies responsible have affirmed they're granting licenses for any use of their technology in the implementation of this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document seems to be supported by multiple implementers and operators as reflecting current or planned practice, with the benefits and caveats described. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (*** authors please run idnits in "very verbose" mode and review-- there are a couple of places where bracketed reference format is used where I believe the unbracketed form is considered correct, but I think most of the update_references warnings are from using RFC 2119 terms in-line, in their non-normative sense.) There are a number of update_references warnings from idnits. A couple are substantive (RFC 7199 was obsoleted by RFC 8499), a couple are harder to parse (they flag external references e.g. [DikeBreaks]). Many are due to the extensive discussion of changes in meaning of terms now considered RFC2119-normative as used in a much older RFC (1034). The warning about an improper URL is spurious (it's a live URL, not an example, and it's in an "Implementation Experience" section that will be removed prior to publication.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC1034 and RFC 1035. The shepherd believes the intended effect is clear. (*** Authors may wish to edit so that all updated RFCs are explicitly discussed in the Introduction.) (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are no actions for IANA in this document, and it has no impact on the meaning of any existing IANA registry or allocated codepoint. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2019-08-26
|
06 | Suzanne Woolf | Changed consensus to Yes from Unknown |
2019-08-26
|
06 | Suzanne Woolf | Updates Internet Standard as defined in RFC 1034 and 1035. |
2019-08-26
|
06 | Suzanne Woolf | Intended Status changed to Proposed Standard from None |
2019-08-08
|
06 | Warren Kumari | New version available: draft-ietf-dnsop-serve-stale-06.txt |
2019-08-08
|
06 | (System) | New version approved |
2019-08-08
|
06 | (System) | Request for posting confirmation emailed to previous authors: Puneet Sood , Warren Kumari , David Lawrence |
2019-08-08
|
06 | Warren Kumari | Uploaded new revision |
2019-07-02
|
05 | Suzanne Woolf | Notification list changed to Suzanne Woolf <suzworldwide@gmail.com> |
2019-07-02
|
05 | Suzanne Woolf | Document shepherd changed to Suzanne Woolf |
2019-06-24
|
Jenny Bui | Posted related IPR disclosure: Akamai Technologies, Inc's Statement about IPR related to draft-ietf-dnsop-serve-stale | |
2019-06-24
|
Jenny Bui | Posted related IPR disclosure: Akamai Technologies, Inc's Statement about IPR related to draft-ietf-dnsop-serve-stale | |
2019-06-21
|
Jenny Bui | Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-dnsop-serve-stale | |
2019-06-21
|
Jenny Bui | Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-dnsop-serve-stale | |
2019-04-16
|
05 | David Lawrence | New version available: draft-ietf-dnsop-serve-stale-05.txt |
2019-04-16
|
05 | (System) | New version approved |
2019-04-16
|
05 | (System) | Request for posting confirmation emailed to previous authors: Puneet Sood , Warren Kumari , David Lawrence |
2019-04-16
|
05 | David Lawrence | Uploaded new revision |
2019-03-09
|
04 | David Lawrence | New version available: draft-ietf-dnsop-serve-stale-04.txt |
2019-03-09
|
04 | (System) | New version approved |
2019-03-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: Puneet Sood , Warren Kumari , David Lawrence |
2019-03-09
|
04 | David Lawrence | Uploaded new revision |
2019-02-23
|
03 | Warren Kumari | New version available: draft-ietf-dnsop-serve-stale-03.txt |
2019-02-23
|
03 | (System) | New version approved |
2019-02-23
|
03 | (System) | Request for posting confirmation emailed to previous authors: Puneet Sood , Warren Kumari , David Lawrence |
2019-02-23
|
03 | Warren Kumari | Uploaded new revision |
2018-11-04
|
02 | Tim Wicinski | Added to session: IETF-103: dnsop Mon-1350 |
2018-10-14
|
02 | David Lawrence | New version available: draft-ietf-dnsop-serve-stale-02.txt |
2018-10-14
|
02 | (System) | New version approved |
2018-10-14
|
02 | (System) | Request for posting confirmation emailed to previous authors: David Lawrence , Puneet Sood , dnsop-chairs@ietf.org, Warren Kumari |
2018-10-14
|
02 | David Lawrence | Uploaded new revision |
2018-09-28
|
01 | Warren Kumari | New version available: draft-ietf-dnsop-serve-stale-01.txt |
2018-09-28
|
01 | (System) | New version approved |
2018-09-28
|
01 | (System) | Request for posting confirmation emailed to previous authors: David Lawrence , dnsop-chairs@ietf.org, Warren Kumari |
2018-09-28
|
01 | Warren Kumari | Uploaded new revision |
2018-05-03
|
00 | (System) | Document has expired |
2017-10-30
|
00 | Tim Wicinski | This document now replaces draft-tale-dnsop-serve-stale instead of None |
2017-10-30
|
00 | David Lawrence | New version available: draft-ietf-dnsop-serve-stale-00.txt |
2017-10-30
|
00 | (System) | WG -00 approved |
2017-10-30
|
00 | David Lawrence | Set submitter to "David C Lawrence ", replaces to draft-tale-dnsop-serve-stale and sent approval email to group chairs: dnsop-chairs@ietf.org |
2017-10-30
|
00 | David Lawrence | Uploaded new revision |