Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-11

[Ballot comment]
I find myself curious about both SHOULDs in

  Resolver software SHOULD treat the response to the priming query as a
  normal DNS response, just as it would use any other data fed to its
  cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs.
 
Do you think these SHOULDs (especially the first one) are required for interoperation? I'm wondering (1) why they aren't MUSTs, and (2) why RFC 2119 language is actually needed at all. If they are RFC 2119 SHOULDs, what happens if the resolver software violates them?

[Ballot comment]
Thank you for producing a well written artefact.

I also support Stephen's request to identify the scenarios in which "Some implementers have chosen other directions, some of which work well and others of which fail (sometimes disastrously) under different conditions." An appendix would be fine IMHO.

Given you raise some (awareness) issues in the security consideration section, if an administrator implements RFC7706 would that alter any of those concerns? (admittedly, potentially buying others that are well documented in 7706)

[Ballot comment]

- intro: References for directions that fail "disastrously"
would be good, if only to decrease the chances that other
implementers choose known-bad approaches.

- section 5, 2nd para: such an attacker can also see what
queries are being emitted by the resolver, and, in the
absence of qname minimisation, that can be quite privacy
sensitive. I think it'd be well worth noting that with a
reference to RFC7816 as a possible mitigation.

[Ballot comment]
In section 3.1, is there a reason the requirement in paragraph 2 does not get a 2119 keywords, when the requirement in the first paragraph does? They seem similar in impact.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-dnsop-resolver-priming-09.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, joelja@gmail.com, draft-ietf-dnsop-resolver-priming@ietf.org, "Tim Wicinski" , dnsop@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Initializing a DNS Resolver with Priming Queries) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Initializing a DNS Resolver with Priming Queries'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 RRSet for the root zone and the necessary address
  information for reaching the root servers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5452: Measures for Making DNS More Resilient against Forged Answers (Proposed Standard - IETF stream)
    rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream)
    rfc3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements (Proposed Standard - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type:      Best Current Practice

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 RRSet for the root zone and the necessary address
information for reaching the root servers.


2. Review and Consensus


This document has been active in the working group for several years. It
had strong consensus to adopt and publish.  However, due to working
group inertia and authors busy schedules, the document stalled several times.
It was picked back up recently and the document went through an editing
process to streamline the language.

This time through the process there was enough attention paid by the working
group to address any outstanding issues, provide editorial comments, and see
the document through.

3. Intellectual Property

The authors stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed.

4. Other Points

There are no downward references to this document, and the shepherd is
satisfied with this.

IANA Considerations:
    There are no IANA Considerations


Checklist

X - Does the shepherd stand behind the document and think the document is
ready for publication?

X - Is the correct RFC type indicated in the title page header?

X - Is the abstract both brief and sufficient, and does it stand alone as
a brief summary?

X - Is the intent of the document accurately and adequately explained in
the introduction?

X - Have all required formal reviews (MIB Doctor, Media Type, URI,
etc.) been requested and/or completed?

X - Has the shepherd performed automated checks

X - Has each author stated that their direct, personal knowledge of any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79?

X - Have all references within this document been identified as either
normative or informative, and does the shepherd agree with how they have
been classified?

X - Are all normative references made to documents that are ready for
advancement and are otherwise in a clear state?

X - If publication of this document changes the status of any existing RFCs,
are those RFCs listed on the title page header, and are the changes
listed in the abstract and discussed (explained, not just mentioned)
in the introduction?

X - If this is a "bis" document, have all of the errata been considered?

X - IANA Considerations: