Last Call Review of draft-ietf-dnsop-no-response-issue-14
review-ietf-dnsop-no-response-issue-14-secdir-lc-meadows-2019-12-19-00

Request Review of draft-ietf-dnsop-no-response-issue
Requested rev. no specific revision (document currently at 23)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-12-19
Requested 2019-12-05
Authors Mark Andrews, Ray Bellis
Draft last updated 2019-12-19
Completed reviews Tsvart Last Call review of -14 by David Black (diff)
Secdir Last Call review of -14 by Catherine Meadows (diff)
Genart Last Call review of -14 by Wassim Haddad (diff)
Opsdir Last Call review of -14 by Dan Romascanu (diff)
Intdir Telechat review of -17 by Carlos Pignataro (diff)
Assignment Reviewer Catherine Meadows 
State Completed
Review review-ietf-dnsop-no-response-issue-14-secdir-lc-meadows-2019-12-19
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Q7GzFf58Jf3VHPRvEpyI90MfALc
Reviewed rev. 14 (document currently at 23)
Review result Has Nits
Review completed: 2019-12-19

Review
review-ietf-dnsop-no-response-issue-14-secdir-lc-meadows-2019-12-19

This draft concerns maintaining the correctness of DNS servers.  It lists the common mistakes that noncompliant servers make in responding to queries and gives the correct ones.  It also gives a set of tests operators can give to their servers ensure compliance, as well as directions for applying the tests.

One of the main security issues  discussed is the fact that many servers are configured not to respond to queries outside of their scope because these are construed as an attack, when in fact these are legal queries that should be responded too (generally with a message saying that these are not supported) and that failure to respond can give be misinterpreted as packet loss, given an incorrect picture of the state of the network.   The document also discusses the security implications of such misleading responses.   

The document also warns about security risks of testing, and of removing non-compliant servers, and alternative means of handling these situations. 

All of the above information is summed up in the security considerations section , and most of it is discussed at more detail in the document itself.

I think that the authors have done an excellent job of identifying and explaining security issues, and I consider the document Ready except for one nit.  In the places where the security considerations section sums up issues that are discussed in more depth in the document itself (e. g. the first , on the fact that none of the tests should cause any harm to a protocol-compliant server), it would be useful to have a pointer to the section of sections where this information appears.