Last Call Review of draft-ietf-dnsop-root-loopback-02

Request Review of draft-ietf-dnsop-root-loopback
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-09-29
Requested 2015-07-30
Authors Warren Kumari, Paul Hoffman
Draft last updated 2015-09-17
Completed reviews Genart Last Call review of -02 by Roni Even (diff)
Secdir Last Call review of -02 by Matt Lepinski (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Opsdir Telechat review of -04 by Dan Romascanu (diff)
Assignment Reviewer Matt Lepinski 
State Completed
Review review-ietf-dnsop-root-loopback-02-secdir-lc-lepinski-2015-09-17
Reviewed rev. 02 (document currently at 05)
Review result Has Nits
Review completed: 2015-09-17


I have reviewed this document as part of the security directorate’s

ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area

directors.  Document editors and WG chairs should treat these comments

just like any other last call comments.

This draft is essentially ready for publication (with minor comments below).

This is an Informational document that specifies how the operator of a recursive resolver could run a copy of the root zone on a loopback interface. The purpose of this mechanism are two-fold: (1) to speed response time in the case of a negative response from the root zone; (2) to hide queries to the root zone from malicious observers. 

The security story for this mechanism is essentially:

A) Since this mechanism must be run on a loopback interface, there is no possibility that the mechanism will negatively impact other entities. (I.e., it would be bad if a recursive resolver started giving authoritative answers for the root zone to anyone other than itself.)

B) DNSSEC is used to ensure that the answers provided by this mechanism are valid.

The security considerations section for this document is somewhat terse and I believe the document could be improved by expanding that section. In particular, I believe that point (A) above should be stated explicitly in the security considerations section. (That is, it is stated elsewhere in the document that using a loopback mechanism is essential. However, I think that repeating that in the security considerations section would be helpful -- I think that point is an important part of the story for why this mechanism doesn't break things.)

Additionally, in the security considerations section, the authors are somewhat brief in describing the need for DNSSEC. I think that is fine, but given the brevity, I think it would be helpful to have a citation to another document that describes why DNSSEC is needed. (Is RFC 4033 the best reference regarding what DNSSEC protects against? Or is there a better document now?)

- Matt Lepinski