On Sat, Jan 10, 2015 at 10:05 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> Wearing my co-author hat: > > On Dec 29, 2014, at 2:23 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > - Given the unsigned nature of the glue in the zone, and the importance > of root glue, it might be the right time to also introduce a "zone > signature" RR, signed by the ZSK. > > It might be, but that certainly would not go in this document. Having said > that, it would be good to first hear evidence about how many resolvers take > the unsigned root glue on faith versus how many chase down the names > themselves. If there is only a small percentage who use the unsigned root > glue, adding a new zone signature RR would seem awfully heavy-weight. (I > say that as someone who has already done a design for the RR and presented > it as a possibly-useful idea; I'm now not convinced it is worth the effort.) > The problem with chasing down the names is that the names are not in signed zones (root-servers.net for example, but many TLD's name server names are in unsigned zones.) I was surprised to learn this, and back when there were only a few hundred TLDs, had trouble finding TLDs whose name server names *were* in signed zones. Maybe the issue is moot, if the AXFR sources are configured by IP address rather than name, and don't factor into the attack surface. The downside is, if there is a need to change the AXFR IP address, presuming a large installed base, how would that happen? On the other hand, if AXFR addresses are looked up in DNS, it becomes a "capture" issue. If an attacker manages to poison the cache of the operator, the attacker can capture the AXFR itself and provide a modified root zone with good signed data but bad glue data. This becomes an undetectable and unrecoverable situation. The use of a zone signature would protect against this, for comparatively low cost. > > > - Given the lack of the "big red button", this would be a good time to > introduce the ability to opt-in to a NOTIFY "registry", so that > appropriately validated notifications could be sent by a root-zone operator > (from whom the root-loopback operator does AXFRs) > > It might be, but that certainly would not go in this document. Still, I > don't see the need for this if the root-loopback operator is checking for > updates at a reasonable rate. The next draft will have a note about the > history of root zone updates. > Ah, rIght, there could be a big difference between RR TTLs and SOA REFRESH. I was thinking of the former, not the latter. > > > - I'd also suggest adding something like a "sentinel" query for SOA > Serial Number be made at REFRESH intervals to randomly-selected root > servers. If the SOA Serial Number is stale for REFRESH + RETRY, it may be > safer to go SERVFAIL at that point rather than waiting for EXPIRE. (The > stale zone might still want to be used if all other root servers become > unreachable, so don't delete the zone, just prefer not to use it.) > > What does "safer" mean here? If the folks who create the root zone (or any > zone, for that matter) want people to expire sooner, they should change the > value of the EXPIRE field: they shouldn't rely on us second-guessing them. > > For most current situations, any zone which is being served by a secondary/slave (including the root zone), normally is done with the knowledge and intent of the zone owner/operator, and (at least for best practices) is monitored by the zone operator. As such, it is generally a rare event for EXPIRE to take effect, at least anecdotally speaking. The root-loopback draft changes the operation of the root zone instances from "all managed by one of the root operators" to "loosely managed by resolver operators". The benefits of having local root zones may be compelling, but IMHO the implementation of this may require more cautious approaches to boundary conditions. Fail safe, to put it in simple terms. "Safer" means, "This should never happen", and if it does, something extremely odd has happened. If the SOA serial is consistently behind some other reference SOA serial source, it means that either the zone updates have been failing, or the upstream masters are themselves stale. Without an additional master from whom to [AI]XFR, this is an "error" condition for which there is no available solution via established mechanisms. Ideally, the root-loopback host should be configured to AXFR from any/all root servers, which I think makes the scenario impossible. If the host only does AXFR from a subset of (or only one of) the root servers, the scenario goes from impossible to possible (regardless of how likely, or via what chain of events). Basically, if the SOA serial has changed, but we aren't using the new copy of the zone (i.e. our copy's serial is older), then by definition we are using a stale copy of the zone. At that point, the only way to get non-stale answers is to query something other than the local (root-loopback) root servers. I'm suggesting that how this error condition is handled, might better reflect how a resolver operator would handle it (human intervention) than how an authority server operator would handle it. Actually, I think authority server operators would also take intervention steps if the scenario existed (a persistently stale slave). I'm thinking that the logic for this should be "What would Joe do?". :-) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
