(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