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 |