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 worth mentioning what the correct response should be. 3.2.6 - It sounds like the misbehaviour being described is response without an EDNS option, rather than non-response, but it's not absolutely clear. I can read the first sentence either way. Potential confusion is increased by the inclusion of the second sentence, which very clearly describes a response, not non-response. Response without an EDNS option would be a variation from the topic of the document (non-response), and so if that's what the authors are discussing here it should be called out clearly. Some possible suggestions, depending on the original intent: Some nameservers only respond to EDNS queries when the DO bit is also set, and drop queries where EDNS options are present but DO is 0. EDNS support is independent of DNSSEC support, and servers that support EDNS should always respond appropriately to queries with EDNS options set. Additionally 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. or Some nameservers respond correctly to EDNS options when the DO bit is set, but drop EDNS options from responses when DO is 0. EDNS support is independent of DNSSEC support, and servers that support EDNS should always respond appropriately to queries with EDNS options set. Additionally 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. 3.2.7 - some words about correct behaviour, or why this behaviour is incorrect, would be helpful here. Section 7 - Last review I recommended some text for paragraph 2 that was neither accepted nor responded to in email. I'll repeat the recommendation here in case it was simply missed: Section 7, paragraph 2: > For unimplemented opcodes NOTIMP is the expected response code. For > example, a new opcode could change the message format by extending > the header or changing the structure of the records etc. > This is not, strictly speaking, an example of what's being talked about in > the previous sentence. Suggested text: > Newly implemented opcodes may change the message format by extending the > header, changing the structure of the records, etc. Servers are not > expected to be able to parse these, and should respond with a response > code > of NOTIMP when they encounter a query with an unknown opcode, rather > than > dropping the message. Likewise, I don't see any response to my comments about section 8. Section 8: > Most of the second paragraphs of the subsections of 8 are written with the > general structure of: > We expect A with B and C and D. > I find this to be awkward list construction. I think it would be more > useful to structure these as: > We expect A, B, C, and D. > For example, subsection 8.1.2: > We expect no records to be returned in the answer section with the > rcode set to NOERROR and the AA and QR bits to be set in the > response; RA may also be set [RFC1034]. We do not expect an OPT > record to be returned [RFC6891]. > This could be: > We expect no records to be returned in the answer section, the rcode to > be > set to NOERROR, and the AA or QR bits to be set in the header; RA may > also > be set [RFC1034]. We do not expect an OPT record to be returned > [RFC6891]. > I'm happy to provide suggested text for all of these if that's useful to > the authors. > > 8.1.3.1, first paragraph. Too many "and"s, not enough commas. :) > Suggested text: > Ask for the SOA record of the configured zone. This query is made > with only the CD DNS flag bit set, all other DNS bits clear, and > without EDNS. > 8.2.3, first paragraph: > Any unassigned EDNS option code could have be choose for this test. > Any unassigned EDNS option code could have been choosen for this test. > > Nits: 3.2.5, second paragraph: "Some EDNS aware server...." should be "Some EDNS aware servers..."
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
