A Common Operational Problem in DNS Servers: Failure to Communicate
draft-ietf-dnsop-no-response-issue-23
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-09-09
|
23 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-09-03
|
23 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-05-11
|
23 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-04-16
|
23 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-23.txt |
2020-04-16
|
23 | (System) | New version approved |
2020-04-16
|
23 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews , Ray Bellis |
2020-04-16
|
23 | Mark Andrews | Uploaded new revision |
2020-04-14
|
22 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-22.txt |
2020-04-14
|
22 | (System) | New version approved |
2020-04-14
|
22 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews , Ray Bellis |
2020-04-14
|
22 | Mark Andrews | Uploaded new revision |
2020-04-13
|
21 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-21.txt |
2020-04-13
|
21 | (System) | New version approved |
2020-04-13
|
21 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2020-04-13
|
21 | Mark Andrews | Uploaded new revision |
2020-04-13
|
20 | (System) | RFC Editor state changed to EDIT |
2020-04-13
|
20 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-04-13
|
20 | (System) | Announcement was received by RFC Editor |
2020-04-13
|
20 | (System) | IANA Action state changed to No IANA Actions |
2020-04-13
|
20 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-04-13
|
20 | Amy Vezza | IESG has approved the document |
2020-04-13
|
20 | Amy Vezza | Closed "Approve" ballot |
2020-04-13
|
20 | Amy Vezza | Ballot approval text was generated |
2020-04-13
|
20 | Amy Vezza | Ballot writeup was changed |
2020-04-09
|
20 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2020-04-08
|
20 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-04-08
|
20 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-04-08
|
20 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-04-08
|
20 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-04-08
|
20 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-04-08
|
20 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. I also like the extensive test scenarios with 'dig' ;-) To be honest, I … [Ballot comment] Thank you for the work put into this document. I also like the extensive test scenarios with 'dig' ;-) To be honest, I was about to ballot a DISCUSS as I have some doubts whether the objective of removing non-compliant servers (end of section 2) is achievable... Too many non-compliant servers, probably managed by clueless people. But, hey, we can always try! I also wonder why this document is a generic BCP while section 8 and other parts seem to indicate more like a testing of servers. Balloting NO OBJECTION but also long hesitation for a DISCUSS. Please address the nits found by Carlos during the INTDIR review: https://mailarchive.ietf.org/arch/msg/int-dir/wfKo4vDmFJwPa1HeDY9wxP2JdEA (at least one nit is already addressed, thank you) Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Generic: the objective of this document is a little unclear to me, is it to do compliance testing/certification specific DNS server software ? or to actual DNS servers on the Internet. -- Section 1 -- Suggest to also add middle-box dropping EDNS in the sentence "Due to the inability to distinguish between packet loss and nameservers dropping EDNS" (see section 4). -- Section 4 -- Why limiting the middle boxes to only firewalls and load balancers? There are many different types of middle-box (NAT, ...) also doing "packet massaging" on the fly... :-( -- Section 10 -- The security considerations is rather weak... If the intent is to probe Internet servers, then why not adding some text around 'do it only with prior agreement of the DNS servers operator' ? Also, if the firewall is "protecting" the DNS server (cough cough), then as a security officer I would prefer to block all unknown opcodes/types at the firewall (possibly with a reply). == NITS == -- section 2 -- Please add an expansion or a reference to "AD flag bit". (and in my non-native English speaker, it is a pleonasm). |
2020-04-08
|
20 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-04-07
|
20 | Barry Leiba | [Ballot comment] Thanks for a BCP on this. I agree with Ben about the commas. For what it’s worth, I disagree with Martin’s comment about … [Ballot comment] Thanks for a BCP on this. I agree with Ben about the commas. For what it’s worth, I disagree with Martin’s comment about “should” and such: the document does not cite BCP 14, and I think that’s fine. Some editorial stuff: — Section 1 — While there is still a pool of servers that don't respond to EDNS requests, clients have no way to know if the lack of response is due to packet loss, or EDNS packets not being supported, I tripped on the meaning of “while” here, and I suggest changing it to “As long as there are still servers...”, so as to avoid the ambiguity. — Section 2 — Some are caused directly from the non-compliant behaviour and others as a result of work-arounds Make it “directly by”, not “from”. And then “and others are as a result”. o Widespread non-response to EDNS queries has lead to recursive Make it “has led”. servers to have to decide whether to probe to see if it is the EDNS option or just EDNS that is causing the non response. I would say, “the specific EDNS option or the use of EDNS in general”. |
2020-04-07
|
20 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-04-07
|
20 | Roman Danyliw | [Ballot comment] Thanks for this document – it is allows for a very approachable way to verify conformance. ** Section 2. Per “Working around issues … [Ballot comment] Thanks for this document – it is allows for a very approachable way to verify conformance. ** Section 2. Per “Working around issues due to non-compliance with RFCs is not sustainable”, this seems like a bold statement. What is the basis for it? ** Section 4. This section repeats several times that firewall should not drop DNS traffic with unknown parameters and such traffic should not be construed as an attack. In the general case with “normal clients”, this is good advice. However, for certain highly controlled enclaves where a white-list-style approach to traffic is taken, this is not realistic. The presence of unexpected classes of new DNS traffic would be a bad sign (e.g., of compromise, a new software load whose features were not understood, or a configuration which was not validated) ** Section 8. For completeness, per “The test below use dig from BIND 9.11.0”, please provide a reference. ** Section 8 dig examples. It would be worth explaining $zone and $server. ** Section 10. Per “Testing protocol compliance can potentially result in false reports of attempts to break services from Intrusion Detection Services and firewalls.”, thanks for calling this out. I would recommend tuning this language: -- s/break services/attack services/ -- to acknowledge that uncommon DNS protocol fields or traffic (from this test regime) might trigger anomaly-detection/profile-based IDS alerts too ** Editorial Nits: -- Section 8. s/is know/is known/ |
2020-04-07
|
20 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-04-07
|
20 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-20.txt |
2020-04-07
|
20 | (System) | New version approved |
2020-04-07
|
20 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews , Ray Bellis |
2020-04-07
|
20 | Mark Andrews | Uploaded new revision |
2020-04-07
|
19 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-04-07
|
19 | Benjamin Kaduk | [Ballot comment] Someone (maybe the RFC Editor) will end up tweaking a lot of commas. I didn't try to list them all. I didn't see … [Ballot comment] Someone (maybe the RFC Editor) will end up tweaking a lot of commas. I didn't try to list them all. I didn't see a response to the secdir reviewer's question (though I'm also not sure that there's an easy answer to it). Section 1 The existence of servers which fail to respond to queries results in developers being hesitant to deploy new standards. Such servers need nit: it feels a little like a juxtaposition to have "developers" that "deploy" new standards (vs. "developers that implement" or "operators that deploy"). indication that the server is under attack. Parent zone operators are advised to regularly check that the delegating NS records are consistent with those of the delegated zone and to correct them when they are not [RFC1034]. Doing this regularly should reduce the instances of broken delegations. I can't tell if this 1034 reference is for the recommendation to regularly check or the definition of "consistent" or something else; if the recommendation is new, then would BCP 14 keywords be appropriate? Section 2 o The AD flag bit in a response cannot be trusted to mean anything as some servers incorrectly copy the flag bit from the request to the response [RFC1035], [RFC4035]. Would it be worth a 6840 ref here as well (to catch setting AD in a request, even though that's not exactly what's being mentioned)? Section 3.1.2 (Do we want to remind the reader on the NOERROR vs. NXDOMAIN rules? "No" is probably acceptable. I see we do so later, in Section 7, so even a forward reference might suffice.) Where's the first reference/mention of Meta-RRs? I see RFC 2929 (obsoleted, transitively, by 6895) that we cite for the "range reserved for private use" but not for terminology. Even RFC 8499 (which we don't cite) only has "meta-RR" in a parenthetical in the description of OPT. Section 3.1.5 micro-nit: I guess firewalls don't exactly count as "nameservers", which seems to be the claimed scope for this document. Section 3.2.1 This section threw me a bit, at first, as the 3.1.x had led me to expect "nameservers should behave in this way", but this section is "here is how to tell if a nameserver is misbehaving". That's not necessarily a problem, just a ... comment :) Section 3.2.6 Some nameservers fail to copy the DO bit to the response despite clearly supporting DNSSEC by returning an RRSIG records to EDNS queries with DO=1. I'm not sure if we also want an explicit "nameservers should copy to the DO bit to the response when they support DNSSEC". Section 3.2.7 [similarly an affirmative statement of what nameservers should do might be appropriate here.] Section 4 Firewalls and load balancers can affect the externally visible behaviour of a nameserver. Tests for conformance should to be done from outside of any firewall so that the system is tested as a whole. (These are conformance tests run by the nameserver's own operator, or externally-driven tests, too?) However, there may be times when a nameserver mishandles messages with a particular flag, EDNS option, EDNS version field, opcode, type or class field or combination thereof to the point where the integrity of the nameserver is compromised. Firewalls should offer the ability to selectively reject messages using an appropriately constructed response based on all these fields while awaiting a fix from the nameserver vendor. I would suggest reiterating that this is "with a response" vs. "drop the packet silently". Section 5 Ideally, Operators should run these tests against a packet scrubbing service to ensure that these tests are not seen as attack vectors. It feels like maybe the most we can say here is "not seen as attack vectors during normal operation". We can't exclude the possibility that some actor decides to generate a flood of messages that happens to match the test behavior (whether by accident or design), which seems fairly likely to lead to blocking of the test-behavior traffic as collateral damage. Section 7 If the server does not support EDNS at all, FORMERR is the expected error code. That said a minimal EDNS server implementation requires parsing the OPT records and responding with an empty OPT record in the additional section in most cases. There is no need to interpret any EDNS options present in the request as unsupported EDNS options are expected to be ignored [RFC6891]. Additionally EDNS flags can be ignored. The only part of the OPT record that needs to be examined is the version field to determine if BADVERS needs to be sent or not. It seems like there's an implied "so providing minimal EDNS support is pretty trivial and you ought to do so already" in here; do we want to make such sentiment explicit? Section 8 Testing is divided into two sections. "Basic DNS", which all servers should meet, and "Extended DNS", which should be met by all servers that support EDNS (a server is deemed to support EDNS if it gives a valid EDNS response to any EDNS query). If a server does not support EDNS it should still respond to all the tests. Is this "respond to all the tests, albeit with [error responses]"? The tests below use dig from BIND 9.11.0. I guess this version could become important if some future version starts setting a new flag by default (that would need to be suppressed if that version of dig was used for many of these tests). Section 8.1.2 Ask for the TYPE1000 RRset at the configured zone's name. This query is made with no DNS flag bits set and without EDNS. TYPE1000 has been chosen for this purpose as IANA is unlikely to allocate this type in the near future and it is not in a range reserved for private use [RFC6895]. Any unallocated type code could be chosen for this test. Is there a risk that since we document TYPE1000 like this some server will implement "respond to TYPE1000" without implementing the actual desired behavior? Section 8.1.3.2 AD use in queries is defined in [RFC6840]. (Knowing this would have been helpful up in the toplevel section 8 where we talk about one or both AD=1 and DO=1 being a signal to expect AD=1.) Section 8.2.3, 8.2.6 [Same comment about option code 100 as for TYPE1000 above; the same response is assumed.] Section 9 When notification is not effective at correcting problems with a misbehaving name server, parent operators can choose to remove NS record sets (and glue records below) that refer to the faulty server until the servers are fixed. This should only be done as a last resort and with due consideration, as removal of a delegation can have unanticipated side effects. [...] I have mixed feelings about recommending "cut you off until you fix your bugs" as an option, but not strongly enough to override WG consensus. |
2020-04-07
|
19 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-04-07
|
19 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-04-05
|
19 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-19.txt |
2020-04-05
|
19 | (System) | New version approved |
2020-04-05
|
19 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2020-04-05
|
19 | Mark Andrews | Uploaded new revision |
2020-04-04
|
18 | Erik Kline | [Ballot comment] {Yes} [nits] S3.2.2 * s/answers responses/responses/ (or answers) S5 * Is there a reference for a definition of "scrubbing service"? S10 * s/None … [Ballot comment] {Yes} [nits] S3.2.2 * s/answers responses/responses/ (or answers) S5 * Is there a reference for a definition of "scrubbing service"? S10 * s/None the tests/None of the tests/ |
2020-04-04
|
18 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2020-03-30
|
18 | Murray Kucherawy | [Ballot comment] General: Nits: * I tripped almost every time on saying "set FOO bit to 1" and similar because I'm used to "set" implying … [Ballot comment] General: Nits: * I tripped almost every time on saying "set FOO bit to 1" and similar because I'm used to "set" implying one and "not set" or "clear" implying zero. In other places the prose does go with simply saying "FOO bit is set". Maybe that's just me though; we'll see how my colleagues feel. Section 1: * Suggest including a reference to RFC4732 in the discussion of amplification attacks. Section 2: * In the discussion of abandoned transition to the SPF type, suggest a reference to RFC6686. Nits: * "Widespread non-response to EDNS queries has lead to ..." -- s/lead/led/ * "Widespread non-response to EDNS options, requires ..." -- remove comma * "... requires recursive servers to have to decide ..." -- s/to have// * "... being present, leads to ..." -- remove comma Section 3.1.2: A nit: * "The exception to this are ..." -- either s/exception/exceptions/ or s/are/is/. Section 3.1.5: A nit: * "While firewalls should not block TCP connection attempts if they do they should ..." -- suggest: "While firewalls should not block TCP connection attempts, those that do should ..." Section 3.2.2: More nits: * "... version 0 queries but ... version numbers that are higher than zero." -- why the digit in one place but prose in the other? Section 4: * Paragraphs 3, 4, and 5 could be common factored very easily since most of the text is identical. Section 5: * I've never heard of a "scrubbing service". Is there a reference RFC, or could we include a short definition? * "One needs to take care when choosing a scrubbing service." -- This is vague. What, apart from the prior sentence (whose implications I don't understand), should an operator be looking for? Section 8: Nit: * "Testing is divided into two sections." -- a list follows, so s/./:/ Section 9: * The final paragraph suggests disconnection of broken nameservers. This can have serious non-technical implications as well. That might be worth mentioning. Nit: * "Name server operators ..." -- s/Name server/Nameserver/, to be consistent with the rest of the document |
2020-03-30
|
18 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record |
2020-03-28
|
18 | Murray Kucherawy | [Ballot comment] [ballot position under construction] General: Nits: * I tripped almost every time on saying "set FOO bit to 1" and similar because I'm … [Ballot comment] [ballot position under construction] General: Nits: * I tripped almost every time on saying "set FOO bit to 1" and similar because I'm used to "set" implying one and "not set" or "clear" implying zero. In other places the prose does go with simply saying "FOO bit is set". Maybe that's just me though; we'll see how my colleagues feel. Section 1: * Suggest including a reference to RFC4732 in the discussion of amplification attacks. Section 2: * In the discussion of abandoned transition to the SPF type, suggest a reference to RFC6686. Nits: * "Widespread non-response to EDNS queries has lead to ..." -- s/lead/led/ * "Widespread non-response to EDNS options, requires ..." -- remove comma * "... requires recursive servers to have to decide ..." -- s/to have// * "... being present, leads to ..." -- remove comma Section 3.1.2: A nit: * "The exception to this are ..." -- either s/exception/exceptions/ or s/are/is/. Section 3.1.5: A nit: * "While firewalls should not block TCP connection attempts if they do they should ..." -- suggest: "While firewalls should not block TCP connection attempts, those that do should ..." Section 3.2.2: More nits: * "... version 0 queries but ... version numbers that are higher than zero." -- why the digit in one place but prose in the other? Section 4: * Paragraphs 3, 4, and 5 could be common factored very easily since most of the text is identical. Section 5: * I've never heard of a "scrubbing service". Is there a reference RFC, or could we include a short definition? * "One needs to take care when choosing a scrubbing service." -- This is vague. What, apart from the prior sentence (whose implications I don't understand), should an operator be looking for? Section 8: Nit: * "Testing is divided into two sections." -- a list follows, so s/./:/ Section 9: * The final paragraph suggests disconnection of broken nameservers. This can have serious non-technical implications as well. That might be worth mentioning. Nit: * "Name server operators ..." -- s/Name server/Nameserver/, to be consistent with the rest of the document |
2020-03-28
|
18 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2020-03-26
|
18 | Martin Duke | [Ballot comment] Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types. A few nits: - … [Ballot comment] Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types. A few nits: - Section 1 has a number of acronyms without clear references (DANE, SPF, TLSA). Please define them on first use. - Sec. 3.1.5. Please add a comma after "attempts" - Sec 3.2.4 uses lower case versions of the normative keywords. Selecting a synonym would improve it. |
2020-03-26
|
18 | Martin Duke | Ballot comment text updated for Martin Duke |
2020-03-26
|
18 | Martin Duke | [Ballot comment] Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types. A few nits: - … [Ballot comment] Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types. A few nits: - Section 1 has a number of acronyms without clear references (DANE, SPF, TLSA). Please define them on first use. - Sec. 3.1.5. Please add a comma after "attempts" - Sec 3.2.4 uses lower case versions of the normative keywords. Selecting a synonym would improve it. |
2020-03-26
|
18 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-03-22
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-03-22
|
18 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-18.txt |
2020-03-22
|
18 | (System) | New version approved |
2020-03-22
|
18 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2020-03-22
|
18 | Mark Andrews | Uploaded new revision |
2020-03-22
|
17 | Carlos Pignataro | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2020-03-17
|
17 | Warren Kumari | IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup |
2020-03-16
|
17 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2020-03-16
|
17 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2020-03-16
|
17 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-03-15
|
17 | Warren Kumari | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2020-03-15
|
17 | Warren Kumari | IESG state changed to IESG Evaluation::AD Followup from Waiting for Writeup::AD Followup |
2020-03-11
|
17 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-03-11
|
17 | Cindy Morgan | Placed on agenda for telechat - 2020-04-09 |
2020-03-11
|
17 | Warren Kumari | Ballot has been issued |
2020-03-11
|
17 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2020-03-11
|
17 | Warren Kumari | Created "Approve" ballot |
2020-03-11
|
17 | Warren Kumari | Ballot writeup was changed |
2020-03-11
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-03-11
|
17 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-17.txt |
2020-03-11
|
17 | (System) | New version approved |
2020-03-11
|
17 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2020-03-11
|
17 | Mark Andrews | Uploaded new revision |
2020-03-10
|
16 | Warren Kumari | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup |
2020-03-08
|
16 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-16.txt |
2020-03-08
|
16 | (System) | New version approved |
2020-03-08
|
16 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2020-03-08
|
16 | Mark Andrews | Uploaded new revision |
2020-03-08
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-03-08
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-03-08
|
15 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-15.txt |
2020-03-08
|
15 | (System) | New version approved |
2020-03-08
|
15 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2020-03-08
|
15 | Mark Andrews | Uploaded new revision |
2020-02-06
|
14 | Warren Kumari | 2020-02-06 - Reminded authors to post new version / asked for status - https://mailarchive.ietf.org/arch/msg/dnsop/fY3vSZO-oBOfUGbl29cLWU7ty8E |
2020-01-27
|
14 | Warren Kumari | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2020-01-17
|
14 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Wassim Haddad. Submission of review completed at an earlier date. |
2020-01-16
|
14 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2020-01-03
|
14 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Wassim Haddad. |
2019-12-23
|
14 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-12-23
|
14 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dnsop-no-response-issue-14, 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-no-response-issue-14, 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-12-19
|
14 | Catherine Meadows | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Catherine Meadows. Sent review to list. |
2019-12-19
|
14 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-12-17
|
14 | David Black | Request for Last Call review by TSVART Completed: Ready. Reviewer: David Black. Sent review to list. |
2019-12-17
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2019-12-17
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2019-12-12
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2019-12-12
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2019-12-12
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2019-12-12
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2019-12-08
|
14 | Wesley Eddy | Request for Last Call review by TSVART is assigned to David Black |
2019-12-08
|
14 | Wesley Eddy | Request for Last Call review by TSVART is assigned to David Black |
2019-12-05
|
14 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-12-05
|
14 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-12-19): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , … The following Last Call announcement was sent out (ends 2019-12-19): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , draft-ietf-dnsop-no-response-issue@ietf.org, warren@kumari.net Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'A Common Operational Problem in DNS Servers - Failure To Communicate.' as Best Current Practice 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 last-call@ietf.org mailing lists by 2019-12-19. 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 DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. The document does not look at the DNS data itself, just the structure of the responses. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream) rfc3225: Indicating Resolver Support of DNSSEC (Proposed Standard - IETF stream) rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - IETF stream) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream) |
2019-12-05
|
14 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-12-05
|
14 | Warren Kumari | Last call was requested |
2019-12-05
|
14 | Warren Kumari | Last call announcement was generated |
2019-12-05
|
14 | Warren Kumari | Ballot approval text was generated |
2019-12-05
|
14 | Warren Kumari | Ballot writeup was generated |
2019-12-05
|
14 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
2019-12-05
|
14 | Warren Kumari | Changed consensus to Yes from Unknown |
2019-11-17
|
14 | Tim Wicinski | 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) The RFC is being requested as BCP (2) Technical Summary Failing to respond to DNS queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of DNS queries which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. Working Group Summary The document initially perscribed remediation for failing to respond correctly. After much working group debate, this wording was removed and the document focused on documenting the failure scenarios. Document Quality Document quality is good and has been through several reviews. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document went through an exhaustive review by the Document Shepherd. We went through several editorial iterations during the working group process before WGLC. We feel the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) WG Consensus is solid. There has been many iterations and comments from a broad spectrum of working group participants. (10) There has been no appeals. (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. (12) No formal reviews needed. (13) All references have been identified as either normative or informative (14) There are no normative references waiting to advance. (15) There are no downward normative references (16) This RFC will not change any existing RFCs. (17) No IANA Considerations. (18) No new IANA Registries (19) N/A |
2019-11-15
|
14 | Tim Wicinski | 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) The RFC is being requested as BCP (2) Technical Summary Failing to respond to DNS queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of DNS queries which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. Working Group Summary The document initially perscribed remediation for failing to respond correctly. After much working group debate, this wording was removed and the document focused on documenting the failure scenarios. Document Quality Document quality is good and has been through several reviews. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document went through an exhaustive review by the Document Shepherd. We went through several editorial iterations during the working group process before WGLC. We feel the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) WG Consensus is solid. There has been many iterations and comments from a broad spectrum of working group participants. (10) There has been no appeals. (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. (12) No formal reviews needed. (13) All references have been identified as either normative or informative (14) There are no normative references waiting to advance. (15) There are no downward normative references (16) This RFC will not change any existing RFCs. (17) No IANA Considerations. (18) No new IANA Registries (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. |
2019-11-15
|
14 | Tim Wicinski | Responsible AD changed to Warren Kumari |
2019-11-15
|
14 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-11-15
|
14 | Tim Wicinski | IESG state changed to Publication Requested from I-D Exists |
2019-11-15
|
14 | Tim Wicinski | IESG process started in state Publication Requested |
2019-11-15
|
14 | Tim Wicinski | 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) The RFC is being requested as BCP (2) Technical Summary Failing to respond to DNS queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of DNS queries which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. Working Group Summary The document initially perscribed remediation for failing to respond correctly. After much working group debate, this wording was removed and the document focused on documenting the failure scenarios. Document Quality Document quality is good and has been through several reviews. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari (3) The Document went through an exhaustive review by the Document Shepherd. We went through several editorial iterations during the working group process before WGLC. We feel the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) WG Consensus is solid. There has been many iterations and comments from a broad spectrum of working group participants. (10) There has been no appeals. (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. (12) No formal reviews needed. (13) All references have been identified as either normative or informative (14) There are no normative references waiting to advance. (15) There are no downward normative references (16) This RFC will not change any existing RFCs. (17) No IANA Considerations. (18) No new IANA Registries (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. |
2019-11-04
|
14 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-14.txt |
2019-11-04
|
14 | (System) | New version approved |
2019-11-04
|
14 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2019-11-04
|
14 | Mark Andrews | Uploaded new revision |
2019-08-29
|
13 | (System) | Document has expired |
2019-08-01
|
13 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-07-17
|
13 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2019-02-25
|
13 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-13.txt |
2019-02-25
|
13 | (System) | New version approved |
2019-02-25
|
13 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2019-02-25
|
13 | Mark Andrews | Uploaded new revision |
2018-11-04
|
12 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-12.txt |
2018-11-04
|
12 | (System) | New version approved |
2018-11-04
|
12 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2018-11-04
|
12 | Mark Andrews | Uploaded new revision |
2018-07-27
|
11 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-11.txt |
2018-07-27
|
11 | (System) | New version approved |
2018-07-27
|
11 | (System) | Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews |
2018-07-27
|
11 | Mark Andrews | Uploaded new revision |
2018-07-20
|
10 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-10.txt |
2018-07-20
|
10 | (System) | New version approved |
2018-07-20
|
10 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews , dnsop-chairs@ietf.org |
2018-07-20
|
10 | Mark Andrews | Uploaded new revision |
2018-07-18
|
09 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-09.txt |
2018-07-18
|
09 | (System) | New version approved |
2018-07-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews |
2018-07-18
|
09 | Mark Andrews | Uploaded new revision |
2017-09-04
|
08 | (System) | Document has expired |
2017-03-03
|
08 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-08.txt |
2017-03-03
|
08 | (System) | New version approved |
2017-03-03
|
08 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews , dnsop-chairs@ietf.org |
2017-03-03
|
08 | Mark Andrews | Uploaded new revision |
2017-03-02
|
07 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-07.txt |
2017-03-02
|
07 | (System) | New version approved |
2017-03-02
|
07 | (System) | Request for posting confirmation emailed to previous authors: Mark Andrews , dnsop-chairs@ietf.org |
2017-03-02
|
07 | Mark Andrews | Uploaded new revision |
2016-10-27
|
06 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-06.txt |
2016-10-27
|
06 | (System) | New version approved |
2016-10-27
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Mark Andrews" , dnsop-chairs@ietf.org |
2016-10-27
|
06 | Mark Andrews | Uploaded new revision |
2016-09-18
|
05 | Mark Andrews | New version approved |
2016-09-18
|
05 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-05.txt |
2016-09-18
|
05 | Mark Andrews | New version approved |
2016-09-18
|
05 | Mark Andrews | Request for posting confirmation emailed to previous authors: "Mark Andrews" , dnsop-chairs@ietf.org |
2016-09-18
|
05 | (System) | Uploaded new revision |
2016-08-26
|
04 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-04.txt |
2016-04-06
|
03 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-03.txt |
2016-02-21
|
02 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-02.txt |
2015-11-30
|
01 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-01.txt |
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 Best Current Practice from None |
2015-11-28
|
00 | Tim Wicinski | This document now replaces draft-andrews-dns-no-response-issue instead of None |
2015-11-28
|
00 | Mark Andrews | New version available: draft-ietf-dnsop-no-response-issue-00.txt |