On 3/11/15, 16:52, "Tony Finch" <d...@dotat.at> wrote: >Edward Lewis <edward.le...@icann.org> wrote: >> >> Note that my request was not for a means to update the parent but to >> prevent the child from shooting themselves in the foot. A much less >> involved operation. > >In this immediate case the problem was caused by a change of operator for >the zone, and the registrar(s) failed to handle DNSSEC properly as part of >the transfer.
The case you are describing is different from what I have been writing about. Different, just as important to solve. (This is why discussing these in a public forum is good - it would be unwise to solve only what I had in mind.) >I think this is a simpler situation to deal with than a botched key >rollover, assuming registrars can be persuaded to add the necessary sanity >checks to their processes. This doesn't have to be anything ambitious like >fully secure domain transfers: either stop the transfer or ask the >registrant to make the domain insecure if the nameservers are changed and >the new ones do not have a properly signed zone. I disagree that is is simpler, starting from stating that "assuming registrars can be persuaded." Persuading registrars to take any steps on the grounds that the steps would improve technology has proven to be somewhere between impossible to it happened once. I want to avoid besmirching registrars but they are not rewarded by being superior in technology. I am not saying that registrars can't listen to reason, but history has shown that they do not take on cost willingly. In a world where a customer (retail enterprise for example) makes a choice for a domain name registrar and a separate choice for DNS hosting, the dynamics are that the customer had to smartly manage having someone that will handle registration of a name and someone that runs the technical function of the DNS. "Smartly manage" meaning they have to watch both and have to act as a go-between. In the short term, changes to the status quo will only happen from the side of the DNS operator. That's where the pain is felt. Expecting change from any other element of the ecosystem is not going to pay off, partly because the DNS operator has the most to gain from changes (lowered costs, increased opportunity to add value added features). DNS operators rely on tools, which is why I've been trying to press for better tooling. I expect DNS operator have to describe what is needed in the way of tool improvements in a manner that tool developers can understand and build (hopefully multiple, interoperable) tools to meet. This is kind of what the IETF has promised to be. What the IETF helps with is the Note Well and wider review, but the IETF requires the participants to expend the energy, "it" doesn't do the work. So, back to this. The new operator is the one that is going to have to red flag the situation. I've seen abuses of when glue records are forgotten at a registry - stale glue doesn't stop operation but I've seen a live example of how it can be used to disrupt an (evidently) ex-employer's systems. While the registration transfer is one process where this check could happen, that would be a needed change and it isn't clear to me whether the a change in DNS operator is "visible" to the process. (There has been some related work in this space - I haven't been following this closely in the last year plus: https://tools.ietf.org/html/draft-ietf-eppext-keyrelay-01.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
