Re: [DNSOP] DNSSEC in draft-ietf-dnsop-resolver-priming

[Matthäus Wander <[e-mail]>]

Paul Hoffman wrote on 2016-01-23 21:47:
> On 22 Jan 2016, at 14:44, Wessels, Duane wrote:
> 
>> I think I'm okay with "resolvers SHOULD send DO when priming."  Seems
>> like BIND and Unbound already do this.
> 
> Noted. Waiting to hear from a bunch more people on this.

No objection.

>> Do we also need to say that the resolver SHOULD/MUST retry with DO=0
>> if there is no response to the first priming query?
> 
> Personal opinion: yes for SHOULD, but we need to integrate it with the
> earlier text about going to a different server if you don't get a
> response within 2 seconds.

This is only useful if validation is disabled and should be stated
accordingly.

>> The more important question may be: what shall the resolver do if
>> validation of the priming response fails? I'm skeptical that we, as a
>> group, will be willing to say that the resolver should refuse to
>> forward any queries to a root unless validation succeeds.
> 
> Personal opinion: agree. We can say that it is local policy. One
> possible policy is to keep trying other hints until one response validates.

Yep, this matches the standard implementation behavior of handling bogus
responses: discard response and try again. If it keeps failing, give up
and don't update the root hints. There's no need to stop communicating
with root.

There's another issue: once root-servers.net is signed, the priming
response will contain RRSIG in the ADDITIONAL section.
1) What if there's not enough space for all RRSIG and the server omits
some of them? (which seems to be allowed according to RFC 4035 Sec. 3.1.1)
2) What if the ANSWER section validates (i.e. response is not bogus) but
some of the addresses in the ADDITIONAL section fail to validate?

I suggest that validators use the following approach:
- If root-servers.net is signed, validate the ANSWER section as usual.
- Attempt to validate all address records. If any of them is bogus or
incomplete (A, AAAA or RRSIG missing), query directly for the server
name and validate the response, e.g. A/a.root-servers.net.

This behavior is consistent with Sec. 4.2 in the current draft ("...
issue direct queries for A and AAAA RRSets for the remaining names.")

Regards,
Matt