[dns-operations] What would it take...

[Edward Lewis]

On 3/11/15, 16:52, "Tony Finch" <dot at dotat.at> wrote:

>Edward Lewis <edward.lewis at 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.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150312/478077fe/attachment.bin>