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

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 21 Jan 2016 19:22:23 -0800

In Warren's review of the draft, he says:

I think that resolvers SHOULD send DO, and should try validate (if it 
gets signed responses). This is pointless at the moment, but if / when 
we end up with signed root-servers.net (or foo.bar) it would be nice if 
the right things were already being done.

This seems like a good start for a discussion.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 22 Jan 2016 22:44:27 +0000

I think I'm okay with "resolvers SHOULD send DO when priming."  Seems like BIND and Unbound already do this.

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?

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.

DW

> On Jan 21, 2016, at 7:22 PM, Paul Hoffman <[email-masked]> wrote:
> 
> I think that resolvers SHOULD send DO, and should try validate (if it gets signed responses). This is pointless at the moment, but if / when we end up with signed root-servers.net (or foo.bar) it would be nice if the right things were already being done.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 23 Jan 2016 12:47:27 -0800

> like BIND and Unbound already do this.

Noted. Waiting to hear from a bunch more people on this.

> 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.

> 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.

--Paul Hoffman

---

From: Matthäus Wander <[email-masked]>
Date: Sat, 23 Jan 2016 23:25:18 +0100

> Noted. Waiting to hear from a bunch more people on this.

No objection.

> response within 2 seconds.

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

> 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

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 26 Jan 2016 22:32:45 +0000

> On Jan 23, 2016, at 2:25 PM, Matthäus Wander <[email-masked]> wrote:
> 
> 

Indeed.  According to my simple test if root-servers.net is signed (the
same way as the root zone), the response size jumps quite a bit:

EDNS0?  UDPsize  DO=  RSN signed?  resp size
------  -------  ---  -----------  ---------
  n        -      -        n         492-512
  y       4096    0        n             755
  y       4096    1        n             913
  y       8192    1        y            4081

And these sizes could increase if two remaining letters decide to add AAAA records.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 26 Jan 2016 22:56:29 +0000

> On Jan 26, 2016, at 2:32 PM, Wessels, Duane <[email-masked]> wrote:
> 

Actually the last case should be larger but I used BIND for testing which
limits edns-udp-size to 4096 on the server.

DW