On 11/24/15, 16:24, "Wessels, Duane" <dwess...@verisign.com> wrote:
>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. Okay, I've been myopically focused on 5011 for some time now. That's my story and I'm sticking to it. >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. You're right that the need is wider than 5011 cases. In an effort to simplify and streamline this (for reasons I'll include later), what about telling a querier to only send this option when it is sending a query to an IP address that is authoritative for the DNSKEY set? I mean that as a toss-up question. Can the querier know when that is happening? I believe so but I don't know if implementations can tell that (in time). What I'm trying to rule out are "stubs" that are sending queries to "upstream" validators or forwarders. The reason for this is to limit the times a stub exposes the trust anchors it has (in case one is known to be exploitable) and to avoid having to come up with rules for union-ing the possible lists of key tags. Or, to ask another toss up - is there benefit in telling the upstream what trust anchors are held? (If there's a conflict between the two (which could also be sever clock skew), use 'CD' in queries.) I'm not sure there's a benefit telling anyone other than the authority for the trust anchors about the set held. Now what I am trying to imagine is how the receiver of the option reacts. I don't know that I'd recommend any active reaction - like trying to inform the querier that their set of tags is out of date. I have the sense that there might be a benefit within a small use case but trying to do that would proliferate corner cases as well as work against the loose coupling that allows DNS to work at scale. I imagine I'd look at packet traces to see what is being sent in, counting IP addresses with/by tags of interest. I.e., out of band (to port 53) massaging of the data and reacting to it. While I realize that during a key roll there will always be late comers, having a gauge of how many are ready for new signatures is helpful to the roll process. The response - what would be in it? Should it be empty? Should it include a set of tags (but what set of tags?). I ask the last because the authoritative server would be configured or deduce the set of tags it sees which might not agree with what a RFC 5011 validator may have picked up. (I.e., keys in the AddPend state are trust anchors in the server, not mature enough to be trusted in the client.) Should it be the set of intended trust anchors or the set of what is thought a 5011 validator (there that focus goes again) would think the tags should be?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
