--- 1/draft-ietf-dnsop-7706bis-08.txt 2020-03-02 17:13:24.605277721 -0800 +++ 2/draft-ietf-dnsop-7706bis-09.txt 2020-03-02 17:13:24.633278431 -0800 @@ -1,32 +1,34 @@ Network Working Group W. Kumari Internet-Draft Google Obsoletes: 7706 (if approved) P. Hoffman Intended status: Informational ICANN -Expires: September 2, 2020 March 1, 2020 +Expires: September 3, 2020 March 2, 2020 Running a Root Server Local to a Resolver - draft-ietf-dnsop-7706bis-08 + draft-ietf-dnsop-7706bis-09 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. + 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 + 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 obsoletes RFC 7706. [ 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. ] Status of This Memo @@ -36,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 2, 2020. + This Internet-Draft will expire on September 3, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -110,21 +112,21 @@ 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.) This document describes a method for the operator of a recursive resolver to have a complete root zone locally, and to hide queries for the root zone from outsiders. The basic idea is to create an up- to-date root zone service on the same host as the recursive server, and use that service when the recursive resolver looks up root information. The recursive resolver validates all responses from the - root service on the same host, just as it would all validate + root service on the same host, just as it would validate all responses from a remote root server. This design explicitly only allows the new root zone service to be run on the same server as the recursive resolver, in order to prevent the server from serving authoritative answers to any other system. Specifically, the root service on the local system MUST be configured to only answer queries from resolvers on the same host, and MUST NOT answer queries from any other resolver. At the time that RFC 7706 [RFC7706] was published, it was considered @@ -190,22 +192,22 @@ 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Requirements In order to implement the mechanism described in this document: o The system MUST be able to validate every signed record in a zone with DNSSEC [RFC4033]. - o The system MUST have an up-to-date copy of the Key Signing Key - (KSK) [RFC4033] used to sign the DNS root. + o The system MUST have an up-to-date copy of the public part of the + Key Signing Key (KSK) [RFC4033] used to sign the DNS root. o The system MUST be able to retrieve a copy of the entire root zone (including all DNSSEC-related records). o The system MUST be able to run an authoritative service for the root zone on the same host. The authoritative root service MUST 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