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.) > - 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. > - 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. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
