One of the concerns in the document is "when to send the option."
I'll state the assumption that this is most useful for RFC 5011 ["Automated Updates of DNS Security (DNSSEC) Trust Anchors"] situations. Perhaps it is not exclusively use to that, but I'll presume that for this suggestion. In RFC 5011, section 2.3 "Active Refresh" there is this plus more detail: "A resolver that has been configured for an automatic update of keys from a particular trust point MUST query that trust point (e.g., do a lookup for the DNSKEY RRSet and related RRSIG records)..." (yadda, yadda, yadda) In the sense that there's a concern about a resolver exposing the keys it has, if the option is only to be attached to the queries done to satisfy that requirement above I think the problem is simplified. In this case, the resolver will know that it "needs to know" and it knows where the trust anchors are "homed." I.e., if the resolver cannot directly query the source, then all bets are off, RFC 5011-wise. Now, if my assumption is incorrect, I'd still recommend that the option be added to RFC 5011, section 2.3 mandated queries. Beyond that, I'm not sure what is the appropriate general case for "revealing" ones' configured trust anchors. There'd be no need for "union-ing" the response (section 5.2.1). The temptation to scope creep this is curtailed if this is an "extension" of RFC 5011 as opposed to a general EDNS option. Any network management reason for this would be available through the means the operator does other network maintenance (use of tools to inspect, etc).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
