Last Call Review of draft-ietf-dnsop-root-loopback-02
review-ietf-dnsop-root-loopback-02-opsdir-lc-romascanu-2015-08-13-00

Request Review of draft-ietf-dnsop-root-loopback
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-11
Requested 2015-08-03
Authors Warren Kumari, Paul Hoffman
Draft last updated 2015-08-13
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 Dan Romascanu
State Completed
Review review-ietf-dnsop-root-loopback-02-opsdir-lc-romascanu-2015-08-13
Reviewed rev. 02 (document currently at 05)
Review result Has Issues
Review completed: 2015-08-13

Review
review-ietf-dnsop-root-loopback-02-opsdir-lc-romascanu-2015-08-13












I have reviewed this document as part of the Operational directorate's








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








comments were written with the intent of improving the operational aspects of the








IETF drafts. Comments that are not addressed in last call may be included in AD reviews








during the IESG review.  Document editors and WG chairs should treat these comments








just like any other last call comments.




 




This I-D aims Informational status. It describes an optimization of the DNS recursive resolvers to speed the queries and hide them from external observation by creating an up-to-date root zone server on an IPv4 loopback address on the same
 host as the recursive server. 




 




If implemented the method described by this I-D has an operational impact. I have used the Operational Considerations checklist in Appendix A1 of RFC 5706 for the review result:





 




1.  Has deployment been discussed?  See Section 2.1.




 




       *  Does the document include a description of how this protocol




          or technology is going to be deployed and managed?




 




       *  Is the proposed specification deployable?  If not, how could




          it be improved?




 




       *  Does the solution scale well from the operational and




          management perspective?  Does the proposed approach have any




          scaling issues that could affect usability for large-scale




          operation?




 




       *  Are there any coexistence issues?




 




Yes – deployment is discussed in section 1. Because of the operational risks discussed in the document distributions of recursive DNS servers MUST NOT include configuration for the design defined in this document. 




 




   2.  Has installation and initial setup been discussed?  See




       Section 2.2.




 




       *  Is the solution sufficiently configurable?




 




       *  Are configuration parameters clearly identified?




 




       *  Are configuration parameters normalized?




 




       *  Does each configuration parameter have a reasonable default




          value?




 




       *  Will configuration be pushed to a device by a configuration




          manager, or pulled by a device from a configuration server?




 




       *  How will the devices and managers find and authenticate each




          other?




 




Yes – to the extent that configuration means here keeping an up-to-date copy of the root zone server




 




   3.  Has the migration path been discussed?  See Section 2.3.




 




       *  Are there any backward compatibility issues?




 




N/A – this is not a new version of the protocol, but an optional incremental optimization




 




   4.  Have the Requirements on other protocols and functional




       components been discussed?  See Section 2.4.




 




       *  What protocol operations are expected to be performed relative




          to the new protocol or technology, and what protocols and data




          models are expected to be in place or recommended to ensure




          for interoperable management?




 




N/A – there is no interoperability issue as long as the root zone server is an up-to-date replica of the external server. 




 




   5.  Has the impact on network operation been discussed?  See




       Section 2.5.




 




       *  Will the new protocol significantly increase traffic load on




          existing networks?




 




       *  Will the proposed management for the new protocol




          significantly increase traffic load on existing networks?




 




       *  How will the new protocol impact the behavior of other




          protocols in the network?  Will it impact performance (e.g.,




          jitter) of certain types of applications running in the same




          network?




 




       *  Does the new protocol need supporting services (e.g., DNS or




          Authentication, Authorization, and Accounting - AAA) added to




          an existing network?




 




Yes – Section 1 makes clear that the deployment of this method leads to faster negative responses, and probably has little effect on getting faster positive responses. 




 




   6.  Have suggestions for verifying correct operation been discussed?




       See Section 2.6.




 




       *  How can one test end-to-end connectivity and throughput?




 




       *  Which metrics are of interest?




 




       *  Will testing have an impact on the protocol or the network?




 




Yes – Section 4 includes recommendations about testing proper operation. 




 




   7.  Has management interoperability been discussed?  See Section 3.1.




 




       *  Is a standard protocol needed for interoperable management?




 




       *  Is a standard information or data model needed to make




          properties comparable across devices from different vendors?




 




N/A




 




   8.  Are there fault or threshold conditions that should be reported?




       See Section 3.3.




 




       *  Does specific management information have time utility?




 




       *  Should the information be reported by notifications?  Polling?




          Event-driven polling?




 




       *  Is notification throttling discussed?




 




       *  Is there support for saving state that could be used for root




          cause analysis?




 




N/A




 




   9.  Is configuration discussed?  See Section 3.4.




 




       *  Are configuration defaults and default modes of operation




          considered?




 




       *  Is there discussion of what information should be preserved




          across reboots of the device or the management system?  Can




          devices realistically preserve this information through hard




          reboots where physical configuration might change (e.g., cards




          might be swapped while a chassis is powered down)?




 




Yes – Section 1 recommends that 

distributions of recursive DNS servers MUST NOT include configuration for the design defined in this document.




 




A few more comments.




 




1.

      


The Abstract mentions ‘the cost of adding some operational fragility to the operator’. I am scratching my head about what this means. Adding one more component may always add some ‘fragility’ but in this
 case the result is a behavior optimization, so is this really a cost to be concerned about?





2.

      


Recursive resolver software such as BIND, Unbound, NSD are mentioned – references may help




3.

      


SOA is never expanded




4.

      


Security Considerations may mention the positive effect of keeping the queries internal, thus preventing observation of traffic on the network between the recursive resolver and one or more of the DNS roots.





 




I hope this helps. 




 




Dan