Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
On Wed, 6 Nov 2019 at 09:38, Ray Bellis wrote: > > > On 06/11/2019 13:42, Matthew Pounsett wrote: > > I still have a few comments. There were a few comments from my review > > of -13 that weren't responded to in email, and haven't been updated in > > the text, so I'm repeating them here. > > Hi Matt, > > We sought advice from one of the Chairs as to whether in his reading > such a significant restructuring of the document was warranted when only > one participant was calling for it. > I'm not actually calling for a restructuring of the document. I'm calling for the structure of the document to be followed. Cleaning up section 3 by moving its tests to section 8 and clearly describing non-response problems instead is just following the existing structure of the document. I did leave it open for you to restructure the document if you wish, to actually combine sections 3 and 8. Perhaps this response will encourage others to speak up about whether they think either of those things are important changes. It's possible people saw my review of -13 and didn't feel the need to comment since someone else already had. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
On 06/11/2019 13:42, Matthew Pounsett wrote: I still have a few comments. There were a few comments from my review of -13 that weren't responded to in email, and haven't been updated in the text, so I'm repeating them here. Hi Matt, We sought advice from one of the Chairs as to whether in his reading such a significant restructuring of the document was warranted when only one participant was calling for it. We have not yet had a clear steer on that. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
I still have a few comments. There were a few comments from my review of -13 that weren't responded to in email, and haven't been updated in the text, so I'm repeating them here. As mentioned in my last review, Section 3 seems very confused about what it's trying to accomplish. Some subsections list only correct behaviour, some only list incorrect behaviour, while other sections list only a test for correct behaviour without actually describing either the correct behaviour or the commonly observed misbehaviour. These latter sections are the most confusing, because tests are expected to be in section 8, based on the current structure of the document. If the authors wish to keep the description of problem responses separate from the description of tests, then that should be done throughout the document, and not just for some tests. If the authors wish to mix testing and problem description, then that should be done consistently, and section 8 should be removed entirely. I said in my last review that this isn't an absolute requirement that should block publication, but while the information is all there to be found I still think it's better writing (and therefore an easier document to parse and act on) if sections 3 and 8 are consistent in their content. Presuming that the authors wish to keep problem description and test description separate, then section 3 should be consistent about describing at least good behaviour for each type of query and leaving off tests. Bad behaviour can be assumed to be non-response, based on the subject of the document, but incidental mention of other common misbehaviours or common reasons for misconfiguration wouldn't be out of place, I think. I've done a section-by-section review of 3.x this time, using the assumption that sections 3 and 8 will remain separate. For some sections I'm suggesting specific text to make clear what I think needs to change, but I think all of those subsections of 3 mentioned below need rewriting. Without a clear indication from the authors about which way they want the structure of the document to go, it's hard to commit the time to suggest rewrites for the entire section. It would be good to hear back from the authors about whether they think these issues are non-problems, and why, or whether they intend to address them in a later version. 3.1.1 - A test description leads ahead of correct behaviour. This section doesn't discuss non-response at all. Suggested text: If a zone is delegated to a server, that server should respond to an SOA query for that zone with an SOA record. Failing to respond at all is always incorrect, regardless of the configuration of the server. Responding with anything other than an SOA record in the Answer section indicates a bad delegation. 3.1.2 - A test description leads ahead of describing incorrect behaviour. Correct behaviour is never described. The test should be removed to section 8, and this should just describe failing to respond to unsupported QTypes, and what a correct response should look like. I'm supplying two suggested text blocks, the latter of which incorporates Viktor Dukhovni's suggestion about NOTIMP. Suggested text: Some servers fail to respond to unknown or unsupported types. If a server receives a query for a type that it doesn't recognize, or doesn't implement, it is expected to return the appropriate response as if it did recognize the type but did not have any data for that type: either NOERROR, or NXDOMAIN. or Some servers fail to respond to unknown or unsupported types, while others may respond with an incorrect rcode of NOTIMP. If a server receives a query for a type that it doesn't recognize, or doesn't implement, it is expected to return the appropriate response as if it did recognize the type but did not have any data for that type: either NOERROR, or NXDOMAIN. 3.1.3 - Good behaviour isn't described. 3.1.5 - The test in the second paragraph should be removed to section 8 3.2.1 - This section leads with a test that should be removed to section 8. The final paragraph is useful, but expected good behaviour needs to replace the first two. 3.2.2 - The last sentence of the second paragraph is potentially confusing, I think. Is it talking about misbehaviour of authoritative servers, or misinterpretation by recursive servers of a bad response from authoritative servers? I'm pretty sure it's the latter... so, text: Such answers will [may?] be misinterpreted by the client, and get discarded or treated as new requests. 3.2.3 - This section does not suffer from the problem described above. However, I think it could use some re-ordering to make it even clearer what the correct behaviour is: Some servers fail to respond to EDNS queries with ENDS options set. The original EDNS specification left this behaviour undefined [RFC2671], but the correct behaviour was clarified in [RFC6891]. Unknown EDNS options are supposed to be ignored by the server. 3.2.5, second paragraph - It's
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
Under Response Code Selection we already have: For unimplemented type codes, and in the absence of other errors, the only valid response is NoError if the qname exists, and NameError (NXDOMAIN) otherwise. For Meta-RRs NOTIMP may be returned instead. > On 6 Nov 2019, at 13:03, Viktor Dukhovni wrote: > >> On Nov 4, 2019, at 3:32 PM, internet-dra...@ietf.org wrote: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-14 > > Two comments: > > --- > > Section 3.1.2 discusses non-response to unexpected qtypes, but there > is a closely related case that I think warrants a mention. For example, > the nameservers for mail.protection.outlook.com (which don't support > EDNS, returning FORMERR, hence "+noends") mishandle TLSA and other > unexpected queries: > > i. A TLSA (unexpected qtype) query elicits an incorrect "NOTIMP" response: > > $ dig +norecur +noedns -t tlsa _25._tcp.mail.protection.outlook.com > @ns1-proddns.glbdns.o365filtering.com. > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 5167 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;_25._tcp.mail.protection.outlook.com. IN TLSA > > ii. An "A" query for the same qname correctly returns "NXDOMAIN": > > $ dig +norecur +noedns -t a _25._tcp.mail.protection.outlook.com > @ns1-proddns.glbdns.o365filtering.com. > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23790 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;_25._tcp.mail.protection.outlook.com. IN A > > This demonstrates misuse of "NOTIMP" to signal an unknown qtype, > where a simple NODATA or NXDOMAIN suffices. The NOTIMP rcode is only > appropriate for unsupported opcodes as explained in section 3.1.4. > While I got a response, it is a "bad" response, not substantively > better than no response at all. > > So I'd like to see text that makes it clear that unexpected qtypes > MUST return the same RCODE as would be returned if the qtype were > some expected value, for which no RRset is present in the zone at > the requested qname. If the zone is signed, and the EDNS "DO" bit > is set in the request, any (untruncated) NODATA or NXDOMAIN response > MUST of course include the requisite denial of existence proof. > > --- > > In section 8.2.3, the correction from: > > OLD: Any unassigned EDNS option code could have be choose for this test. > > to > > NEW: Any unassigned EDNS option code could have been choose for this test. > > was incomplete, it needed to also s/choose/chosen/, to match an identical > sentence in 8.2.6. > > -- > Viktor. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
> On Nov 4, 2019, at 3:32 PM, internet-dra...@ietf.org wrote: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-14 Two comments: --- Section 3.1.2 discusses non-response to unexpected qtypes, but there is a closely related case that I think warrants a mention. For example, the nameservers for mail.protection.outlook.com (which don't support EDNS, returning FORMERR, hence "+noends") mishandle TLSA and other unexpected queries: i. A TLSA (unexpected qtype) query elicits an incorrect "NOTIMP" response: $ dig +norecur +noedns -t tlsa _25._tcp.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com. ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 5167 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_25._tcp.mail.protection.outlook.com. IN TLSA ii. An "A" query for the same qname correctly returns "NXDOMAIN": $ dig +norecur +noedns -t a _25._tcp.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23790 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_25._tcp.mail.protection.outlook.com. IN A This demonstrates misuse of "NOTIMP" to signal an unknown qtype, where a simple NODATA or NXDOMAIN suffices. The NOTIMP rcode is only appropriate for unsupported opcodes as explained in section 3.1.4. While I got a response, it is a "bad" response, not substantively better than no response at all. So I'd like to see text that makes it clear that unexpected qtypes MUST return the same RCODE as would be returned if the qtype were some expected value, for which no RRset is present in the zone at the requested qname. If the zone is signed, and the EDNS "DO" bit is set in the request, any (untruncated) NODATA or NXDOMAIN response MUST of course include the requisite denial of existence proof. --- In section 8.2.3, the correction from: OLD: Any unassigned EDNS option code could have be choose for this test. to NEW: Any unassigned EDNS option code could have been choose for this test. was incomplete, it needed to also s/choose/chosen/, to match an identical sentence in 8.2.6. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : A Common Operational Problem in DNS Servers - Failure To Communicate. Authors : M. Andrews Ray Bellis Filename: draft-ietf-dnsop-no-response-issue-14.txt Pages : 26 Date: 2019-11-04 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-14 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
