Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Edward Lewis <[e-mail]>]

On 8/4/16, 20:03, "DNSOP on behalf of Tim Wicinski" <[e-mail] on behalf of [e-mail]> wrote:
>Remember the Resolver Priming draft?

Comments on the draft (https://tools.ietf.org/id/draft-ietf-dnsop-resolver-priming-07.txt):

## 3.3.  DNSSEC with Priming Queries
##
##    The resolver MAY set the DNSSEC OK [RFC4033] bit.  At the time this
##    document is being published, there is little use to performing DNSSEC
##    validation on the priming query because the "root-servers.net" zone
##    is not signed, and so a man-in-the-middle attack on the priming query
##    can result in malicious data in the responses.  However, if the
##    "root-servers.net" zone is later signed, or if the root server
##    operators choose a different zone to identify themselves and that
##    zone is signed, having DNSSEC validation for the priming queries
##    might be valuable.

Recommend against altering the trust anchor settings based on anything learned via priming.  Not that a priming query would contain DS or DNSKEY resources records "normally" (and thus should not have them) but if the idea to "push" additional records comes around again, the priming query is not the place to also update the secure entry points.

In section 4.2:

##    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.  Said another way: in an EDNS
##    response, if the additional section only has an A RRSet for a server,
##    the resolver SHOULD assume that no AAAA RRSet exists.

Is "an EDNS response" a term well-enough defined to be used this way?

A possible rewording ought to include - if the priming query contained, via EDNS, Requestor's Payload Size of more than XXY bytes, the address information...complete.  But this assumes that the priming query Size was large enough, e.g., it wasn't set to be 515 bytes.

## 5.  Security Considerations
##
##    Spoofing a response to a priming query can be used to redirect all of
##    the queries originating from a victim recursive resolver to one or
##    more servers for the attacker.  Until the responses to priming
##    queries are protected with DNSSEC, there is no definitive way to
##    prevent such redirection.

There is one use case I'm concerned about - because it has happened.

http://research.dyn.com/2008/05/identity-theft-hits-the-root-n-1/

In so much as at that article is true, a defense that can be used is to recommend multiple (2 or 3) priming queries and have the receiver check for consistency.  Two might indicate a problem, three can point out which is a problem.  In the absence of DNSSEC validation and the observation that Root System changes happen one at a time and fairly well spread out in time, this might be beneficial to recommend.

I offer this just as a suggestion.  (I've been told my major operators that having at least three sources of information increases reliability.  I'm basing my comment on that, more so than the linked story.)