Subject: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-priming-04.txt

From: [email-masked]
Date: Fri, 14 Feb 2014 15:32:34 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Initializing a DNS Resolver with Priming Queries
        Authors         : Peter Koch
                          Matt Larson
	Filename        : draft-ietf-dnsop-resolver-priming-04.txt
	Pages           : 9
	Date            : 2014-02-14

Abstract:
   This document describes the initial queries a DNS resolver is
   supposed to emit to initialize its cache with a current NS RRSet for
   the root zone as well as the necessary address information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-resolver-priming-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tony Finch <[email-masked]>
Date: Sat, 15 Feb 2014 14:42:17 +0000

This is a worthwhile clarification and update to the original specs.

Some questions and comments:

2.1.  Parameters of a Priming Query

   A priming query SHOULD use a QNAME of "." and a QTYPE of NS.  The
   priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]).

Is this supposed to forbid fallback to TCP? That seems wrong to me.
Fallback to TCP isn't expected in practice, but it seems wasteful to
require extra logic in the resolver to suppress it in this special case.

   The resolver SHOULD also use EDNS0 [RFC6891] and SHOULD announce and
   handle a reassembly size of at least 1024 octets [RFC3226].

Again I think priming queries should use the resolver's normal EDNS buffer
size. It ought to be OK for a resolver on a network with a small MTU and
broken fragment support to advertise a small buffer.

2.2.  Repeating Priming Queries

   A resolver SHOULD NOT originate a priming query more often than once
   per day (or whenever the resolver starts).  It SHOULD adhere to the
   TTL values given in the priming response.

Why the special once per day requirement? Shouldn't this be entirely
driven by the NS RRset TTL?

3.3.  Completeness of the Response

   For an EDNS response, a resolver SHOULD consider the address
   information found in the additional section complete for any
   particular server that appears at all.

   If the resolver did not announce a reassembly size larger than 512
   octets, this assumption is invalid.

This extra SHOULD seems to over-simplify the normal DNS reply processing
rules, which I suppose is what the following paragraph is about. I think
it would be better to describe what is expected to happen non-normatively
rather than imposing new rules.

   [[Issue 2: Do the TTLs for the root NS RRSet and address RRSets in
   the root and the ROOT-SERVERS.NET. zones need to be aligned?  In real
   life responses, the address RRSet's TTL values vary by name server
   implementation.  Is this diversity we can live with?  Should the
   authoritative source prevail?  Is it therefore a protocol issue
   rather than an operational choice of parameters?]]

Oh that's a bit weird and interesting :-)

Looks like some servers fill the additional section with the glue RRs from
the root zone (TTL 6 days) and some with the authoritative RRs from the
root-servers.net zone (TTL 1000 hours).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.