Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Brian Dickson <[e-mail]>]

>
> Richard Gibson <rgibson at dyn.com> wrote:
> > Because without such a signal, humans using ANY for legitimate diagnostic
> > purposes have no means of differentiating section 4.1/4.3 "subset"
> > responses from conventional responses where there just happen to be only
> a
> > small number of RRSets at the queried name, encouraging (or at least
> doing
> > nothing to dissuade) a conclusion that the response is in fact
> conventional
> > and complete.
> There are several ways to avoid this pitfall:
> Use TCP
> Look for an NSEC(3) record
> Query for the specific types you want to know about
> Tony.


I hope it's not too late to discuss additions to the I-D. Sorry for not
contributing sooner.

So, I have a question about EDNS and DNSSEC (and maybe when DO=1):

Suppose a zone is NOT signed, but the requestor uses EDNS (and maybe DO=1).

What would resolvers do if they received, in addition to normal RRs, one or
more NSEC or NSEC3 records, and no RRSIGs?

That would be one way to provide information about RRtypes at the owner
name, even if the zone was unsigned.

Would it be feasible to limit the behavior of "refuse-any" returning
"partial" UDP responses, to situations where EDNS with DO=1 is used? Older
resolvers would need to have some method of getting answers, so maybe for
those, use the TC=1 method?

Specifically:
 When a QTYPE=ANY is received, respond with some "arbitrary" choice of
RRTYPE, and add an unsigned NSEC or NSEC3 record to list RRTYPEs present.

In the case of SIGNED zone, returning a random RRtype and including the
NSEC/NSEC3 would be ideal for both signaling that "ANY" is not supported,
as well as what else to query for.

I think NSEC or NSEC3 could be used in an unsigned zone, and generated "on
the fly" with trival or empty values for "next owner", with the caveat that
it MUST NOT be used for generating negative or empty responses. But that is
a stretch, and probably not worth pursuing without some further
investigation into resolvers' handling of such unsigned responses inside
unsigned zones.

(This on-the-fly suggestion is a compromise to avoid the need for
NSEC/NSEC3 over unsigned zones, or forcing everything to be signed, which
is clearly not yet a reasonable suggestion.)

Thoughts?
Brian