Running a Root Server Local to a Resolver
RFC 8806
Yes
No Objection
Recuse
Note: This ballot was opened for revision 07 and is now closed.
Éric Vyncke Yes
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...
Alvaro Retana No Objection
Roman Danyliw No Objection
Warren Kumari Recuse
Recuse -- 'm an author...
(Alexey Melnikov; former steering group member) Yes
(Barry Leiba; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) No Objection
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 <X>"
vs. just "<X>".)
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.)
(Deborah Brungard; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection