[DNSOP] Re: DNSOPMike Bishop's Discuss on draft-ietf-dnsop-cds-consistency-09: (with DISCUSS and COMMENT)

[Wes Hardaker <[e-mail]>]

Mike Bishop <mbishop=[e-mail]> writes:

> No. I noticed that the (even vague) requirement was missing for CSYNC processing (as Paul pointed out), but there
> is a non-breakage requirement defined for CDS/CDNSKEY processing in RFC 7344 Section 4.1. It simply reads:
> 
>     o  Continuity: MUST NOT break the current delegation if applied to DS
>        RRset.
> 
> My thinking was that it's reasonable to hold CSYNC to the same standard.
> 
> [MB] That's frustrating. I agree that the same standard of not breaking things should apply here, but I'd like to
> see the process spelled out in a little more detail.

Well, to some extent it becomes an implementation specific decision.  I
don't know how much we should dictate exactly what must be checked.
There are certainly many ways to implement this (Paul W. suggested one
involving putting the new records in a validating resolver cache and
then check resolution).  I suspect that there are many ways to perform
such checks, and I doubt we should specify one.

The important bit to me says that we should protect against service
downgrades.  Whether that's implemented on the registrar/registry side
using a simple "query and check the crypto works (CDS)" or "send a query
to the new NSes to verify they aren't broken (CSYNC)", that's up to
them.

Back when I was assigned the role of checking arpa changes for the IAB,
I did things manually: when a new DS was to be inserted, I verified
(with tools) that the DS did belong to a new key that I could also query
for.  This was a manual process, and I'm sure I could have been fooled
into not checking by waiting a TTL as well though.  But at least I did
some level of due diligence to ensure things wouldn't break.

TL;DR: it's right we should add a requirement that things shouldn't
break.  But it's wrong that we should specify exactly how in great
detail that requirement must be executed.  All IMHO.

-- 
Wes Hardaker
Google