[DNSOP] More comments on draft-wessels-edns-key-tag-00

[Edward Lewis <[e-mail]>]

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