Decreasing Access Time to Root Servers by Running One on Loopback
draft-ietf-dnsop-root-loopback-05

After thinking about the comments from Joel and Paul, I'm demoting the IPR question to a comment, since I think it's up to the Joel and the working group to decide if there should be any delay to work this out:

The IPR disclosure at http://datatracker.ietf.org/ipr/2539/ says that due to the early state of the draft, license terms will be provided later. Obviously the draft is beyond early stages now. Does it make sense to ask for an update before progressing this draft?

-- section 1, paragraph 7: "Thus, recursive resolver software such as BIND will not need to add
   much new functionality, but recursive resolver software such as
   Unbound will need to be able to talk to an authoritative server"

It might be useful to mention the properties of BIND and Unbound that make the difference.

-- 1, paragraph 8: "Because of the significant operational risks described in this
   document, distributions of recursive DNS servers MUST NOT include
   configuration for the design described here."

This made my day!

   Malicious third
   parties might be able to observe that traffic on the network between
   the recursive resolver and one or more of the DNS roots
   ....
   The primary goals of this design is to provide faster negative
   responses to stub resolver queries that contain junk queries, and to
   prevent queries and responses from being visible on the network. 

I've been wondering. So this mechanism is basically to speed up junk queries.
What can a malicious third party do by observing junk queries. Nothing, I guess.

I guess you want something like.
OLD:
   The primary goals of this design is to provide faster negative
   responses to stub resolver queries that contain junk queries, and to
   prevent queries and responses from being visible on the network.

NEW: 
   The primary goals of this design is to provide faster negative
   responses to stub resolver queries that contain junk queries, and to
   prevent valid queries and responses from being visible on the network.

Thanks for addressing the comments made in the SecDir review and including the added text:
https://www.ietf.org/mail-archive/web/secdir/current/msg06032.html

I'm with Terry, this isn't new and I'm glad that is pointed out in the ack section.

Thank you for writing this document and describing how it is done and also the risks of doing this, and most importantly why it should not be done on a whim or by default.

I concur that this is not a new idea. In fact I implemented a similar thing during my ISP days in the late 90's and it was certainly more beneficial then due to the low change rate of the root zone, and the absence of DNSSEC, along with slower network speeds, and less instances of anycasted root-serves. That said, the operational costs were the same and they have been well covered in the doc.

Can you please pay a little attention to the first sentence of the security considerations? Its a doozy and I had to re-read it a couple time to be clear on its meaning.

In the appendix, different locations to get the zone by AXFR are specified. Have you considered highlighting that the zone can be collected from authoritative points in other ways?

e.g.

- https://www.iana.org/domains/root/files (noting ftp and http methods. 
- https://http.l.root-servers.org (and plain http)
(and of course there may well be others, but I'll refrain from boiling that ocean)

I would also like to see the observation made that no public AXFR service (that I am aware of) uses TSIG, so the fetching party is at the general risk exposure of non-TSIG AXFR. Not so much in terms of modifying data in the zone (as it's signed and the DNSSEC support on the recursive resolver is a MUST) but in a MiTM effort to simply withhold new versions of the root zone in a DoS frame.