On Sun, Feb 28, 2021 at 12:37 PM Viktor Dukhovni <[email protected]> wrote:
> On Sun, Feb 28, 2021 at 08:52:38PM +0100, Vladimír Čunát wrote: > > > On 2/28/21 8:47 PM, Paul Hoffman wrote: > > >> [1]https://tools.ietf.org/html/rfc8482#section-7 [tools.ietf.org] > > > That RFC (a) doesn't update RFC 4025 and (b) is only about QTYPE of > "ANY". > > > > I meant just the informal future-work note focused on QTYPE=RRSIG (in > > the linked section), to support my claim that there are advantages in > > avoiding full replies to such queries. > > Not only are "full" replies not needed, detached from the RRSet for > which an RRSIG is the signature, the content of the RRSIG is both > useless and meaningless. Since it can never be validated it should not > be cached. > > An interoperable synthetic reply when the qname exists would be: > > <qname> 0 IN RRSIG RRSIG 255 <numlabels> 0 <0x0> <0x0> 0 > <closest-encloser> AA== > > A signature payload of a single 0 byte avoids potential issues with > unexpected zero-length signatures. > > * It is less clear what to do when the qname is wildcard-synthesized. > Should there be NSEC records to validate a wildcard-based response??? > > My take is "no", just always set the closest encloser to equal the > qname, and let the zero TTL take care of not having such replies > stick around in caches to imply anything about the node. > > Iterative resolvers should not cache RRSIG replies, regardless of TTL. > > I'm writing a new stub resolver for Haskell, and even prior to this > thread my plan was to not permit RRSIG queries, because they made no > sense. I could instead just return the above synthetic response without > asking any upstream server, but an error telling the user they're doing > the wrong thing seems more appropriate. > I think this is vaguely interesting, if for no other reason that it exposes some weaknesses in the original 403[345] RFCs. Two relevant questions are: - Are the observed RRSIG queries the result of an actual client's behavior? (The alternative being diagnostic tool usage, and I'd be surprised if it was the former.) - If a validating client is either using a security-oblivious resolver (the client might be a stub or a forwarder), or has an intermediate network device interfering with DNSSEC, is it even possible to do validation, ever? It's clear that the relevant portion(s) of 403[345] don't correctly handle the RRSIG case, and pretty much cannot (since RRSIG needs to know the original QTYPE to select/filter the RRSIG). If (big IF) there is interest in solving for the second case (validating client behind a middle box or resolver that is not returning RRSIG records, possibly not doing EDNS, and may or may not be security-aware with respect to CD and AD bits), what then? It might be interesting to know how much of the Internet is in those situations (validating stub or validating resolver, but unable to actually validate). The follow-up question, if there is a substantial portion of the client base that is impacted, which path is more likely to occur on a timely basis: - Removal/upgrade of resolvers or middle boxes causing these issues - Deployment of new code on resolvers and clients with ways of addressing the RRSIG issue (I don't think there is any real reason or value for auth-only servers to do anything different, or at most only add the auth piece of any new logic.) If the latter (deployment of new code) is the path of least resistance (which would be unpleasant, obviously), the question would then be: how would a client signal to a server, that it wants RRSIG records for a specific signed RRSET/RRTYPE? The assumption would probably be a worst-case scenario: no EDNS, but possibly transparent path for AD/CD bits, and possibly support for new OPCODEs. (Testing real paths might be needed for the OPCODE support.) The methods I can think of are basically: - Underscore added to QNAME, to indicate the second QTYPE (either _RRSIG.QNAME for QTYPE==thing that is signed by the RRSIG, or _QTYPE.QNAME with real QTYPE being RRSIG). - New OPCODE for RRSIG, so instead of OPCODE==0 and QTYPE==FOO, have OPCODE==RRSIG and QTYPE==FOO - The returned reply would either be just the RRSIG of the right QTYPE, or the answer of QTYPE RRSET in the Answer section, and the RRSIG(s) in the Additional section Absent the above, it is probably fair to exclude RRSIG from things that can get sensible answers, and 403[345] should be updated to clarify. (IMHO, the extra logic might not be too bad, and would potentially be useful for advancing the deployment of validating stubs.) Brian
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
