> On Nov 25, 2015, at 6:33 AM, Edward Lewis <edward.le...@icann.org> wrote: > > 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?
For the recursive-to-authoritative case that is exactly what I had in mind. > > 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) Can you say more about how limited you think it should be? Never? In what I'm proposing the stub also would send the option only for DNSKEY queries and only for trust anchor zones (i.e. root). Is that limited enough? Do you have particular concerns about who knows about the stub's trust anchors? Are you thinking of on-path attackers or the recursive operator or something else? Is it okay for a recursive to expose old trust anchors, but not okay for a stub? > and to avoid having to > come up with rules for union-ing the possible lists of key tags. I actually like the suggestion I heard from someone (sorry, can't remember exactly who right now) that instead of intersection or union, the recursive could just forward a second instance of the option. > Or, to > ask another toss up - is there benefit in telling the upstream what trust > anchors are held? I'd say there is a benefit to the zone operator in knowing what trust anchors are in use by stubs. > (If there's a conflict between the two (which could > also be sever clock skew), use 'CD' in queries.) Sorry I didn't follow that. > 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 am fully against any active reaction. The edns-key-tag option should not affect the response in any way, nor cause any "extra" responses. > > 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. Yes. > > 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? Forgive me for saying, but it sounds to me like you might've misunderstood a little about what I proposed. I'm saying the edns-key-tag option rides along with a DNSKEY query. So the response is a normal DNSKEY response. The draft currently says: A responder MUST NOT include the edns-key-tag option in any DNS response. So what I've proposed is one-way, passive data collection only. Note I modeled this after RFC 6975, which works the same way. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
