Hi Ed,
> On Nov 24, 2015, at 9:00 AM, Edward Lewis <edward.le...@icann.org> wrote: > > 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. I'd put it slightly differently. I'd say it is most useful for "configured trust anchors" whether they're updated with RFC 5011, or not. By "configured trust anchor" I mean the trust anchor material that exists outside the name server process, survives restarts and reboots, etc. As currently written the draft also applies to cached trust anchors (i.e., DS records) and I've had people tell me they think that could be useful. But if the consensus is that edns-key-tag should only be reported for configured trust anchors, I could live with that. > > 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. But then you only get data for validators doing 5011 and doing it correctly. This is part of the problem we have with the root -- if there are validators with manually configured keys, we'd like to know about them. OTOH, really nothing in the draft is mandatory (except for the MUST NOTs). So an implementation of edns-key-tag could absolutely choose to only send the values for RFC-5011 queries. > > 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). DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
