Skip to main content

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 revision 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 P. Andrews , Ray Bellis
Draft last updated 2019-12-19
Completed reviews Tsvart Last Call review of -14 by David L. 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 revision 14 (document currently at 23)
Result Has Nits
Completed 2019-12-19
review-ietf-dnsop-no-response-issue-14-secdir-lc-meadows-2019-12-19-00
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.