<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 22px; font-family: Calibri, sans-serif;"><div>...to prevent another DS<-->DNSKEY mishap from happening again?</div><div><br></div><div>I'm presenting the message to the DNS Operations list of DNS-OARC. (Being subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF participant or talking as a past operator of DNS or as ....)</div><div><br></div><div>In short, think about when a name server loads a zone with a DNSKEY set in it. If, at the parent zone, there is a DS set and none of it's contents refer to a record in the DNSKEY set, all DNSSEC validating queries will declare everything in the zone broken.</div><div><br></div><div>So, why can't the name server find the DS set, run a check and barf if there's a problem? Barf - either refusing to load the zone or refusing to change the zone that is already running.</div><div><br></div><div>Here are some impediments:</div><div><br></div><div>1) The entity responsible for the set up is not likely to be a programmer.</div><div>2) Authoritative servers don't launch queries.</div><div>3) Authoritative servers don't know anything about the parent zone.</div><div>4) The owners of the zone and the operator of the DNS are not always the same entity (person, company).</div><div><br></div><div>#1 - The implications of this is - tools/components are needed. One option are management/diagnostic tools. Another option is an embedded in the name server component. More tools is great when you are the jockey, more embedded components is great when you are the customer.</div><div><br></div><div>#2 - Software can do what it wants - but sometimes hidden masters are shielded with the public Internet. (I'll assume the case is that the parent and child zones are on separate sets of machines - when this is't true, we don't have the problem.) I bet though, that it wouldn't be hard to convince the operators of hidden masters to allow them access port 53 outside the firewall.</div><div><br></div><div>#3 - There's a brute force way to overcome this, come down the root to find the cut point. Or this can be configured somehow (but I hate pinning). Or maybe just doing a straight forward use of a validating recursive server (but that's more tools, see #1).</div><div><br></div><div>#4 - This is a critical aspect of the problem. Even if the customer tells the DNS hosting company to roll keys, the customer has to be the one who finds the registrar to ensure the DS set is correct in the registry. That's four participants with the most important (customer) the least capable (or they probably wouldn't be a customer). Failing to automate away the customer's problem will kill the effort, certainly stall scaling.</div><div><br></div><div>The first step is for the operations community to cobble together a solution to this problem. Perhaps a proposal goes to the IETF for the proper review and legal protection. And if there's a need to change other policies, an IETF document might be the greatest asset.</div><div><br></div><div>This is one way to make DNSSEC less clumsy.</div><div><br></div><div>Please - if there are more impediments, suggest them. I may have missed something. If you disagree with an impediment, speak out.</div><div><br></div></body></html>