Subject: [apps-discuss] APPS-Dir review of draft-ietf-dnsop-edns-chain-query-05

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Nov 2015 12:24:48 -0800

I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-dnsop-edns-chain-query-05
Title: Chain Query requests in DNS

Reviewer: Ted Hardie
Review Date: November 23, 2015

Summary:

This is generally suitable as the basis of an experiment, but the document
could describe some of the trade-offs more clearly.

Comments:

Major Issues:

The effort to avoid amplification attacks is appropriate, but justification
of the UDP option, even with the EDNS option for a DNS cookie, is not well
supported in the draft.  One major driver for the work is that the total
response size needed for validation may be large.  Using DNS cookies will
add between 15 and 40 bytes (presuming both client and server cookies are
used), thus further swelling the response.  Some description of when the
requester/responder's UDP payload size is likely to be sufficient here
would be a valuable addition.  If the data is not available now, perhaps it
could be gathered during the course of experimentation? If that data shows
the intersection of "fits within UDP" and "answers at least a partial
chain" is small, then reverting this to TCP-only looks sensible.

Minor Issues:

In 5.4, the document currently describes the process of returning a partial
chain:

   If a CHAIN answer would be bigger than the Recursive Resolver is
   willing to serve, it SHOULD send a partial chain starting with the
   data closest to the top of the chain.  The client MAY re-send the
   query with an updated Closest Trust Point until it has received the
   full chain.  The CHAIN response will contain the lowest Closest Trust
   Point that was included in the CHAIN answer.

This describes the intersection of one particular resource constraint and
the operation of this option.  It seems possible, however that a resolver
might see other resource constraints which might allow it to answer a
partial chain from something other than the data closest to the top of the
chain.  Imagine, for example, that it has cached data for some parts of the
chain but needs to refresh the cache on some other part.  If the cache fill
operation is taking significant time, it might prefer to send what data it
has, and fill the cache in anticipation of the follow-up query.  Is there a
reason for limiting partial answers to the top-most hierarchical
responses?  If so, could the document include it?

In section 6.5, the document says:

   Many paths between DNS clients and Recursive Resolvers suffer from
   poor hygiene, limiting the free flow of DNS messages that include
   particular EDNS0 options, or messages that exceed a particular size.
   A fallback strategy similar to that described in [RFC6891
<https://tools.ietf.org/html/rfc6891>] section
<https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-05#section-6.2.2>
   6.2.2 <https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-05#section-6.2.2>
SHOULD be employed to avoid persistent interference due to non-
   clean paths.

This seems to conflict with the advice in 5.3:

   However, it is RECOMMENDED that Forwarders remember which
   upstream Recursive Resolvers did not return the option (and
   additional data) with their response.  The Forwarder SHOULD fallback
   to regular DNS for subsequent queries to those Recursive Resolvers.
   It MAY switch to another Recursive Resolver that does support the
   CHAIN option or try again later to see if the server has become less
   loaded and is now willing to answer with Query Chains.

To resolve this, the client would have to be able to detect when the ENDS0
option is suppressed by the path, versus not offered by a Recursive
Resolver.   Some further text on how this is discerned would be useful;
absent a method, I believe the text in 5.3 is sufficient and 6.5 not useful
beyond the points made in RFC 6891.

Nits:

The abstract uses the term "security aware validating Resolver".  This use
of "security aware" appears to be the term of art used in RFC 4033, but
that may not be obvious; perhaps "DNSSEC validating resolver" would be more
clear for an abstract?
In section 6.3, the document says:

   In the event that there is greater demand for Chain Queries than can
   be accommodated, DNS servers may stop advertising the CHAIN option in
   successive DNS messages.  This allows, for example, clients with
   other candidate servers to query to establish new sessions with
   different servers in expectation that those servers might still allow
   Chain Queries.

Given that this would also apply to UDP CHAIN queries, it is not clear why
this is in the TCP Session Management section.

In section 6.4, the document says "partian CHAIN up" where it should say
"partial CHAIN up".

In section 6.6, this text was quite hard to parse:

    Changes in network topology between clients and anycast servers may
   cause disruption to TCP sessions making use of CHAIN more often than
   with TCP sessions that omit it, since the TCP sessions are expected
   to be longer-lived.

Perhaps:

Since DNS queries using CHAIN may result in longer TCP sessions,
network topology changes may disrupt them more frequently.