Initializing a DNS Resolver with Priming Queries
RFC 8109

Document Type RFC - Best Current Practice (March 2017; No errata)
Also known as BCP 209
Last updated 2017-03-15
Replaces draft-koch-dnsop-resolver-priming
Stream IETF
Formats plain text pdf html bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Tim Wicinski
Shepherd write-up Show (last changed 2016-09-09)
IESG IESG state RFC 8109 (Best Current Practice)
Consensus Boilerplate Yes
Telechat date
Responsible AD Joel Jaeggli
Send notices to "Tim Wicinski" <tjw.ietf@gmail.com>
IANA IANA review state Version Changed - Review Needed
IANA action state No IC
Internet Engineering Task Force (IETF)                           P. Koch
Request for Comments: 8109                                      DENIC eG
BCP: 209                                                       M. Larson
Category: Best Current Practice                               P. Hoffman
ISSN: 2070-1721                                                    ICANN
                                                              March 2017

            Initializing a DNS Resolver with Priming Queries

Abstract

   This document describes the queries that a DNS resolver should emit
   to initialize its cache.  The result is that the resolver gets both a
   current NS Resource Record Set (RRset) for the root zone and the
   necessary address information for reaching the root servers.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   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).  Further information on
   BCPs is available in 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
   http://www.rfc-editor.org/info/rfc8109.

Copyright Notice

   Copyright (c) 2017 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
   (http://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.

Koch et al.               Best Current Practice                 [Page 1]
RFC 8109                   DNS Priming Queries                March 2017

Table of Contents

   1. Introduction ....................................................2
   2. Description of Priming ..........................................3
   3. Priming Queries .................................................3
      3.1. Repeating Priming Queries ..................................4
      3.2. Target Selection ...........................................4
      3.3. DNSSEC with Priming Queries ................................4
   4. Priming Responses ...............................................5
      4.1. Expected Properties of the Priming Response ................5
      4.2. Completeness of the Response ...............................5
   5. Security Considerations .........................................6
   6. IANA Considerations .............................................6
   7. Normative References ............................................6
   Acknowledgements ...................................................7
   Authors' Addresses .................................................7

1.  Introduction

   Recursive DNS resolvers need a starting point to resolve queries.
   [RFC1034] describes a common scenario for recursive resolvers: they
   begin with an empty cache and some configuration for finding the
   names and addresses of the DNS root servers.  [RFC1034] describes
   that configuration as a list of servers that will give authoritative
   answers to queries about the root.  This has become a common
   implementation choice for recursive resolvers, and is the topic of
   this document.

   This document describes the steps needed for this common
   implementation choice.  Note that this is not the only way to start a
   recursive name server with an empty cache, but it is the only one
   described in [RFC1034].  Some implementers have chosen other
   directions, some of which work well and others of which fail
   (sometimes disastrously) under different conditions.  For example, an
   implementation that only gets the addresses of the root name servers
   from configuration, not from the DNS as described in this document,
   will have stale data that could cause slower resolution.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document only deals with recursive name servers (recursive
   resolvers, resolvers) for the IN class.

Koch et al.               Best Current Practice                 [Page 2]
Show full document text