Skip to main content

Decreasing Access Time to Root Servers by Running One on Loopback
RFC 7706

Revision differences

Document history

Date Rev. By Action
2020-01-21
05 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-12-03
05 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2015-11-24
05 (System) RFC published
2015-11-20
05 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7706">AUTH48-DONE</a> from AUTH48
2015-11-16
05 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7706">AUTH48</a> from RFC-EDITOR
2015-11-16
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-10-14
05 (System) Notify list changed from tjw.ietf@gmail.com, draft-ietf-dnsop-root-loopback.ad@ietf.org, draft-ietf-dnsop-root-loopback@ietf.org, dnsop-chairs@ietf.org, draft-ietf-dnsop-root-loopback.shepherd@ietf.org to (None)
2015-10-09
05 Gunter Van de Velde Request for Telechat review by OPSDIR Completed. Reviewer: Dan Romascanu.
2015-10-06
05 (System) RFC Editor state changed to EDIT
2015-10-06
05 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-10-06
05 (System) Announcement was received by RFC Editor
2015-10-05
05 (System) IANA Action state changed to No IC from In Progress
2015-10-05
05 (System) IANA Action state changed to In Progress
2015-10-05
05 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-10-05
05 Amy Vezza IESG has approved the document
2015-10-05
05 Amy Vezza Closed "Approve" ballot
2015-10-05
05 Amy Vezza Ballot approval text was generated
2015-10-01
05 Paul Hoffman IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-10-01
05 Paul Hoffman New version available: draft-ietf-dnsop-root-loopback-05.txt
2015-10-01
04 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation
2015-10-01
04 Michelle Cotton IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-10-01
04 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-10-01
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-10-01
04 Brian Haberman
[Ballot comment]
Thanks for writing a clear document that describes the approach and the potential pitfalls.  As I noted earlier, I think this approach is …
[Ballot comment]
Thanks for writing a clear document that describes the approach and the potential pitfalls.  As I noted earlier, I think this approach is untenable given the fragility it will introduce.  Any chance we will see a management item in the near future marking the resulting RFC Obsolete?

-- old comments below --

I can't decide if I should ballot Yes because this document does a good job of describing how to deploy this approach or Abstain because the fragility introduced in this approach appears to be untenable.

In the meantime, can someone explain why this document is stating a requirement to deploy this approach with IPv4 only?
2015-10-01
04 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to Yes from No Record
2015-10-01
04 Stephen Farrell [Ballot comment]
Thanks for documenting this. I may try it:-)
2015-10-01
04 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2015-09-30
04 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-09-30
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-09-30
04 Kathleen Moriarty
[Ballot comment]
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 …
[Ballot comment]
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.
2015-09-30
04 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-09-30
04 Ben Campbell
[Ballot comment]
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 …
[Ballot comment]
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!
2015-09-30
04 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2015-09-30
04 Ben Campbell
[Ballot discuss]
This is just a process discuss:

The IPR disclosure at http://datatracker.ietf.org/ipr/2539/ says that due to the early state of the draft, license terms …
[Ballot discuss]
This is just a process discuss:

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?
2015-09-30
04 Ben Campbell
[Ballot comment]
-- section 1, paragraph 7: "Thus, recursive resolver software such as BIND will not need to add
  much new functionality, but recursive …
[Ballot comment]
-- 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!
2015-09-30
04 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2015-09-30
04 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-09-30
04 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-09-30
04 Brian Haberman
[Ballot comment]
I can't decide if I should ballot Yes because this document does a good job of describing how to deploy this approach or …
[Ballot comment]
I can't decide if I should ballot Yes because this document does a good job of describing how to deploy this approach or Abstain because the fragility introduced in this approach appears to be untenable.

In the meantime, can someone explain why this document is stating a requirement to deploy this approach with IPv4 only?
2015-09-30
04 Brian Haberman Ballot comment text updated for Brian Haberman
2015-09-28
04 Benoît Claise
[Ballot comment]
  Malicious third
  parties might be able to observe that traffic on the network between
  the recursive resolver and one or …
[Ballot comment]
  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.
2015-09-28
04 Benoît Claise Ballot comment text updated for Benoit Claise
2015-09-28
04 Benoît Claise
[Ballot comment]
  Malicious third
  parties might be able to observe that traffic on the network between
  the recursive resolver and one or …
[Ballot comment]
  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.
2015-09-28
04 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-09-26
04 Terry Manderson
[Ballot comment]
Thank you for writing this document and describing how it is done and also the risks of doing this, and most importantly why …
[Ballot comment]
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.
2015-09-26
04 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-09-24
04 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2015-09-24
04 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2015-09-17
04 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Dan Romascanu
2015-09-17
04 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Dan Romascanu
2015-09-17
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Matt Lepinski.
2015-09-14
04 Paul Hoffman IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-09-14
04 Paul Hoffman New version available: draft-ietf-dnsop-root-loopback-04.txt
2015-09-13
03 Joel Jaeggli IESG state changed to IESG Evaluation from Waiting for Writeup
2015-09-08
03 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-09-07
03 Joel Jaeggli Ballot has been issued
2015-09-07
03 Joel Jaeggli [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli
2015-09-07
03 Joel Jaeggli Created "Approve" ballot
2015-09-07
03 Joel Jaeggli Ballot writeup was changed
2015-09-07
03 Joel Jaeggli Placed on agenda for telechat - 2015-10-01
2015-09-07
03 Joel Jaeggli Changed consensus to Yes from Unknown
2015-08-13
03 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu.
2015-08-11
03 Paul Hoffman IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-08-11
03 Paul Hoffman New version available: draft-ietf-dnsop-root-loopback-03.txt
2015-08-11
02 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-08-03
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2015-08-03
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2015-07-30
02 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2015-07-30
02 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2015-07-30
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Matt Lepinski
2015-07-30
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Matt Lepinski
2015-07-29
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2015-07-29
02 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-root-loopback-02, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-root-loopback-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.
2015-07-28
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-07-28
02 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <dnsop@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <dnsop@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-dnsop-root-loopback-02.txt> (Decreasing Access Time to Root Servers by Running One on Loopback) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Decreasing Access Time to Root Servers by Running One on Loopback'
  <draft-ietf-dnsop-root-loopback-02.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Some DNS recursive resolvers have longer-than-desired round trip
  times to the closest DNS root server.  Some DNS recursive resolver
  operators want to prevent snooping of requests sent to DNS root
  servers by third parties.  Such resolvers can greatly decrease the
  round trip time and prevent observation of requests by running a copy
  of the full root zone on a loopback address (such as 127.0.0.1).
  This document shows how to start and maintain such a copy of the root
  zone that does not pose a threat to other users of the DNS, at the
  cost of adding some operational fragility for the operator.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2539/



2015-07-28
02 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-07-28
02 Amy Vezza Last call announcement was changed
2015-07-27
02 Joel Jaeggli Last call was requested
2015-07-27
02 Joel Jaeggli Last call announcement was generated
2015-07-27
02 Joel Jaeggli Ballot approval text was generated
2015-07-27
02 Joel Jaeggli Ballot writeup was generated
2015-07-27
02 Joel Jaeggli IESG state changed to Last Call Requested from AD Evaluation
2015-06-28
02 Joel Jaeggli IESG state changed to AD Evaluation from Publication Requested
2015-06-26
02 Amy Vezza Notification list changed to tjw.ietf@gmail.com, draft-ietf-dnsop-root-loopback.ad@ietf.org, draft-ietf-dnsop-root-loopback@ietf.org, dnsop-chairs@ietf.org, draft-ietf-dnsop-root-loopback.shepherd@ietf.org from "Tim Wicinski" <tjw.ietf@gmail.com>
2015-06-26
02 Tim Wicinski
Shepherd Writeup for draft-ietf-dnsop-root-loopback

1. Summary

Who is the document shepherd? Who is the responsible Area Director?

The Document Shepherd is Tim Wicinski.  The Responsible …
Shepherd Writeup for draft-ietf-dnsop-root-loopback

1. Summary

Who is the document shepherd? Who is the responsible Area Director?

The Document Shepherd is Tim Wicinski.  The Responsible Area Director
is Joel Jaggeli.

The document is intended as "Informational" status.  This document
shows how one can start a maintain a copy of the DNS Root Zone data
which can descrease latency, at the cost of adding some operational
fragility.


2. Review and Consensus

This document came out of several different proposals involving
improving the redundancy of the DNS Root Zone.  The document was the
one which the Working Group was able to gather consensus.  The
discussion behind this was engaging as several felt the trade off of
local copies for speed increased operational fragility.  This document
was not written to become a Best Practice or an Internet Standard, but
as an Informational document to explain how operators currently manage
such tasks.


3. Intellectual Property

There is an IPR disclosure related to this document.  The Authors have
already been aware of this IPR disclosure, and no of no other IPR
disclosure related to this document.  The opinion of the working group
is that the IPR party implies a willingness to commit to not requiring
any licenses or royalties.

4. Other Points

There are no downward references.

This document requires no action from IANA.

The Document Shepherd stands behind this document and feels the
document is ready for publication.

The correct RFC type is indicated in the title page.

The shepherd has run automated checks on the document and it passes
all nits, etc.

All references within this document been identified as either
normative or informative and the shepherd agrees with these.  All
normative references are in a clear state.




2015-06-26
02 Tim Wicinski Responsible AD changed to Joel Jaeggli
2015-06-26
02 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2015-06-26
02 Tim Wicinski IESG state changed to Publication Requested
2015-06-26
02 Tim Wicinski IESG process started in state Publication Requested
2015-06-26
02 Tim Wicinski Changed document writeup
2015-06-25
02 Paul Hoffman New version available: draft-ietf-dnsop-root-loopback-02.txt
2015-06-24
01 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2015-06-05
01 Tim Wicinski Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>
2015-06-05
01 Tim Wicinski Document shepherd changed to Tim Wicinski
2015-06-05
01 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2015-02-25
Naveen Khan Posted related IPR disclosure: Verisign Inc.'s Statement about IPR related to draft-ietf-dnsop-root-loopback
2015-01-11
01 Paul Hoffman New version available: draft-ietf-dnsop-root-loopback-01.txt
2014-11-30
00 Tim Wicinski Intended Status changed to Informational from None
2014-11-30
00 Tim Wicinski This document now replaces draft-wkumari-dnsop-root-loopback instead of None
2014-11-30
00 Paul Hoffman New version available: draft-ietf-dnsop-root-loopback-00.txt