Running a Root Server Local to a Resolver
RFC 8806

Document Type RFC - Informational (June 2020; No errata)
Obsoletes RFC 7706
Authors Warren Kumari  , Paul Hoffman 
Last updated 2020-06-18
Replaces draft-kh-dnsop-7706bis
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Suzanne Woolf
Shepherd write-up Show (last changed 2020-01-13)
IESG IESG state RFC 8806 (Informational)
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions


Internet Engineering Task Force (IETF)                         W. Kumari
Request for Comments: 8806                                        Google
Obsoletes: 7706                                               P. Hoffman
Category: Informational                                            ICANN
ISSN: 2070-1721                                                June 2020

               Running a Root Server Local to a Resolver

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.  In both cases, 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.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8806.

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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Changes from RFC 7706
     1.2.  Requirements Notation
   2.  Requirements
   3.  Operation of the Root Zone on the Local Server
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  Current Sources of the Root Zone
     A.1.  Root Zone Services
   Appendix B.  Example Configurations of Common Implementations
     B.1.  Example Configuration: BIND 9.12
     B.2.  Example Configuration: Unbound 1.8
     B.3.  Example Configuration: BIND 9.14
     B.4.  Example Configuration: Unbound 1.9
     B.5.  Example Configuration: Knot Resolver
     B.6.  Example Configuration: Microsoft Windows Server 2012
   Acknowledgements
   Authors' Addresses

1.  Introduction

   DNS recursive resolvers have to provide answers to all queries from
   their clients, even those for domain names that do not exist.  For
   each queried name that is within a top-level domain (TLD) that is not
   in the recursive resolver's cache, the resolver must send a query to
   a root server to get the information for that TLD or to find out that
   the TLD does not exist.  Research shows that the vast majority of
   queries going to the root are for names that do not exist in the root
   zone.

   Many of the queries from recursive resolvers to root servers get
   answers that are referrals to other servers.  Malicious third parties
   might be able to observe that traffic on the network between the
   recursive resolver and root servers.

   The primary goals of this design are to provide more reliable answers
   for queries to the root zone during network attacks that affect the
   root servers and to prevent queries and responses from being visible
   on the network.  This design will probably have little effect on
   getting faster responses to the 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.)

   This document describes a method for the operator of a recursive
Show full document text