Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-12

[Ballot comment]
Abstract

  Some DNS recursive resolvers have longer-than-desired round-trip
  times to the closest DNS root server; those resolvers may have
  difficulty getting responses from the root servers, such as during a
  network attack.  Some DNS recursive resolver operators want to
  prevent snooping by third parties of requests sent to DNS root
  servers.  Such resolvers can greatly decrease the round-trip time and

Can I suggest to s/Such resolvers/In both cases, resolvers/?

Section 1

  The primary goals of this design are to provide more reliable answers
  for queries to the root zone during network attacks, and to prevent
  queries and responses from being visible on the network.  This design
  will probably have little effect on getting faster responses to stub
  resolver for good queries on TLDs, because the TTL for most TLDs is
  usually long-lived (on the order of a day or two) and is thus usually
  already in the cache of the recursive resolver; the same is true for
  the TTL for negative answers from the root servers.  (Although the
  primary goal of the design is for serving the root zone, the method
  can be used for any zone.)

Are there any considerations of note when using this method for a zone
other than the root zone?

Section 1.1

(I expect the RFC Editor will change things to use a consistent
construction for the last five paragraphs, regarding "this document "
vs. just "".)

Section 2

      only respond to queries from the same host.  One way to assure not
      responding to queries from other hosts is to run an authoritative
      server for the root that responds only on one of the loopback
      addresses (that is, an address in the range 127/8 for IPv4 or ::1

nit(?): in principle there's nothing to stop such a service from
responding on more than one loopback address ... not that I can think of
a reason why one would want to.

Section 3

  There is a risk that a system using a local authoritative server for
  the root zone cannot refresh the contents of the root zone before the
  expire time in the SOA.  A system using a local authoritative server
  for the root zone MUST NOT serve stale data for the root zone.  To
  mitigate the risk that stale data is served, the local root server
  MUST immediately switch to using non-local root servers.

Immediately ... upon what condition?

Section 4

We should probably discuss the consequences for when the SHOULD NOT is
ignored and the glue records in the root zone are changed.

  As stated in Section 1, this design explicitly allows the local copy
  of the root zone information to be available only from resolvers on
  that host.  This has the security property of limiting damage to

nit: "allows [...] to be available only from" or "requires [...] to be
available only from"?  (Or "only allows [...] to be available from", of
course.)

[Ballot comment]
Thank you for the work put into this document. With the heavy load on this week telechat and the workload related to the cancellation of the IETF-107 in-person meeting, I must admit that this review was not as thorough as I had hope :-(

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated to my first comment (and possible the other ones).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Out of curiosity, was it considered to run the 'mirror root' on one global anycast address of the root server, e.g., 2001:7fd::1, and modify the root cache to only have this one? (I am sure that you know that Linux can have a 'local' route for any IPv4/IPv6 address to the loopback)

-- Section 1 --
Very minor, s/their customers,/their clients,/ as there is not always a contract

s/during network attacks/during network attacks against the root servers/ ?

The sentence in parenthesis "(Although the..." is important and deserves a paragraph on its own IMHO.

-- Appendix B --
"were checked recently" means little thing... can you replace with "March 2020" ?

-- Section B.1 --
I would have preferred the use of "::1" rather than "127.12.12.12;" in the example...

[Ballot comment]
Small editorial comment:
As this document obsoletes RFC7706 (and does not update it), section 1.1 should probably be called "Changes from RFC7706" (and not " Updates from RFC 7706").

Additional comment from IANA:
Appendix A contains the line "One can also get the root zone from IANA as a text file over HTTPS at ." IANA would like to request that this be changed to "The root zone file can be obtained via methods described at https://www.iana.org/domains/root/files."
We'd recommend this change given the distribution mechanism may evolve over time, and this page can provide description of the various mechanisms.

Closed request for Telechat review by INTDIR with state 'Withdrawn': As Jouni did review for Opsdir and is also on Intdir, his review will be used.

Very small error in the -08 update, “all validate” in the Introduction should be “validate all”.  The revised ID can wait until after IESG Eval if the authors prefer.

There are some minor editorial updates pending from last call reviews, the most significant of which are fixing broken reference links and changing "Updates 7706" to "Obsoletes 7706".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-7706bis-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry 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, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-28):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , suzworldwide@gmail.com, Suzanne Woolf , barryleiba@gmail.com, draft-ietf-dnsop-7706bis@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Running a Root Server Local to a Resolver) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Running a Root Server Local to
a Resolver'
  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
last-call@ietf.org mailing lists by 2020-02-28. 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 such as during a network attack.
  Some DNS recursive resolver operators want to prevent snooping by
  third parties of requests sent to DNS root servers.  Such resolvers
  can greatly decrease the round-trip time and prevent observation of
  requests by serving a copy of the full root zone on the same server,
  such as on a loopback address or in the resolver software.  This
  document shows how to start and maintain such a copy of the root zone
  that does not cause problems for other users of the DNS, at the cost
  of adding some operational fragility for the operator.

  [ This document is being collaborated on in Github at:
  https://github.com/wkumari/draft-kh-dnsop-7706bis.  The most recent
  version of the document, open issues, and so on should all be
  available there.  The authors gratefully accept pull requests. ]




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

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


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested

Informational, as a successor to an Informational document which does not provide any new protocol and which is not intended as a BCP.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up.

Technical Summary:
This document shows how to start and maintain a local copy of the root zone that reduces round-trip times for certain queries, reduces the risk of third-party observation of DNS queries and responses, and does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. It updates RFC 7706 with additional operator experience in using the described techniques.

Working Group Summary:
The original RFC 7706 was published in 2015 as guidance to resolver operators to help them provide local resolution of lookups in the root zone, which has become increasingly popular as a resiliency mechanism for DNS operations, but which can also lead to new failures that might be difficult to troubleshoot. The technique was largely undocumented at the time. The WG expected  that a -bis document would be useful with more experience, and has been correct in this assessment, so insight from that further experience is presented here.
The WG has thoroughly discussed the document and both authors have been responsive and accurate in their work on it.

Document Quality:

The document is based on RFC 7706 and clearly states the premise for going beyond it-- 7706 specified one mechanism, local root server on loopback, for the local root cache; 7706bis discusses others, including operational requirements for configuration to provide the desired service and avoid the pitfalls.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Shepherd: Suzanne Woolf
AD: Barry Leiba (our AD is a co-author)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has reviewed multiple versions of the document and participated in the WG discussions of both 7706 and this document. I’ve also reviewed the WGLC and other recent discussion. The WG appears comfortable with the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No. There was significant experience present in the WG, and extensive discussion.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?
None. This document is squarely within charter for DNSOP and has benefited from extensive WG discussion among people who will use it.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
There are no IPR filings against this draft, and each author has stated they know of no IPR related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
N/A

(9) How solid is the WG consensus behind this document?
There was extensive discussion on the draft between operators and implementers. It appears to have strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No. Not everyone is comfortable with the techniques discussed in the draft because they can cause problems if not carefully applied, but the purpose of the document is to provide guidance for that care.

(11) Identify any ID nits the Document Shepherd has found in this document.
  == There are 18 instances of lines with non-RFC6890-compliant IPv4
    addresses in the document.  If these are example addresses, they should
    be changed.
*** (They are not; they are actual root server addresses.)
  == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.
*** (They are not; they are actual root server addresses.)
  -- The draft header indicates that this document updates RFC7706, but the
    abstract doesn't seem to mention this, which it should.
*** This will be fixed prior to publication.

There is no IPR related material in the document.

References are checked and all normative references are in a clear state.

The publication of the document *does* update RFC 7706

(12) - (15): N/A

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction?
This document updates RFC 7706, which is listed in the document header. Changes from 7706 and the rationale for them are extensively discussed in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.
There are no actions for IANA specified, so the IANA Considerations is the placeholder version (“This document has no actions for IANA.”)

(18) - (20): N/A

(1) What type of RFC is being requested

Informational, as a successor to an Informational document which does not provide any new protocol and which is not intended as a BCP.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up.

Technical Summary:
This document shows how to start and maintain a local copy of the root zone that reduces round-trip times for certain queries, reduces the risk of third-party observation of DNS queries and responses, and does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. It updates RFC 7706 with additional operator experience in using the described techniques.

Working Group Summary:
The original RFC 7706 was published in 2015 as guidance to resolver operators to help them provide local resolution of lookups in the root zone, which has become increasingly popular as a resiliency mechanism for DNS operations, but which can also lead to new failures that might be difficult to troubleshoot. The technique was largely undocumented at the time. The WG expected  that a -bis document would be useful with more experience, and has been correct in this assessment, so insight from that further experience is presented here.
The WG has thoroughly discussed the document and both authors have been responsive and accurate in their work on it.

Document Quality:

The document is based on RFC 7706 and clearly states the premise for going beyond it-- 7706 specified one mechanism, local root server on loopback, for the local root cache; 7706bis discusses others, including operational requirements for configuration to provide the desired service and avoid the pitfalls.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Shepherd: Suzanne Woolf
AD: Barry Leiba (our AD is a co-author)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has reviewed multiple versions of the document and participated in the WG discussions of both 7706 and this document. I’ve also reviewed the WGLC and other recent discussion. The WG appears comfortable with the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No. There was significant experience present in the WG, and extensive discussion.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?
None. This document is squarely within charter for DNSOP and has benefited from extensive WG discussion among people who will use it.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
There are no IPR filings against this draft, and each author has stated they know of no IPR related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
N/A

(9) How solid is the WG consensus behind this document?
There was extensive discussion on the draft between operators and implementers. It appears to have strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No. Not everyone is comfortable with the techniques discussed in the draft because they can cause problems if not carefully applied, but the purpose of the document is to provide guidance for that care.

(11) Identify any ID nits the Document Shepherd has found in this document.
  == There are 18 instances of lines with non-RFC6890-compliant IPv4
    addresses in the document.  If these are example addresses, they should
    be changed.
*** (They are not; they are actual root server addresses.)
  == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.
*** (They are not; they are actual root server addresses.)
  -- The draft header indicates that this document updates RFC7706, but the
    abstract doesn't seem to mention this, which it should.
*** This will be fixed prior to publication.

There is no IPR related material in the document.

References are checked and all normative references are in a clear state.

The publication of the document *does* update RFC 7706

(12) - (15): N/A

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction?
This document updates RFC 7706, which is listed in the document header. Changes from 7706 and the rationale for them are extensively discussed in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.
There are no actions for IANA specified, so the IANA Considerations is the placeholder version (“This document has no actions for IANA.”)

(18) - (20): N/A

1. Summary

Document Shepherd: 
Area Director:      Barry Lieba

Document Type:  Informational

This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost  of adding some operational fragility for the operator.

Informational is appropriate for the document.  It discusses several methods and configurations of running a root name server locally, and why one may do this.


2. Review and Consensus

The document has been reviewed and discussed on the DNSOP mailing list and during DNSOP workgroup meetings.  Contributions of both text as well as operational deployment experience were provided by many interested folks.  The feedback by the WG was promptly integrated in the document.  No points of difficulty or controversy appeared and consensus was quick.  There has been good consensus during the WGLC period. 

The document shepherd has no specific concerns or issues with the document or with the WG process.  The shepherd stands behind the document and thinks the document is ready for publication.

3. Intellectual Property
There are no IPR filings against this draft, and each author has stated they know of no IPR related to this document.

4. Other Points

There are no downward references.

There is currently no IANA Considerations section, so there are no relevant IANA Considerations.


!Nits Report:

** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

  == There are 18 instances of lines with non-RFC6890-compliant IPv4
    addresses in the document.  If these are example addresses, they should
    be changed.

  == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.

  -- The draft header indicates that this document updates RFC7706, but the
    abstract doesn't seem to mention this, which it should.



IANA Considerations: N/A

There is no IPR related material in the document.

References are checked and all normative references are in a clear state.

The publication of the document *does* update RFC 7706