Mike Bishop <[email protected]> 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
