Re: [DNSOP] CSYNC. Or CDS. Or something completely different.

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Matthijs Mekking writes:
> Hi,
> 
> In yesterday's meeting, it was not clear to everyone why there are two
> approaches to synchronize records between child and parent. Also, a
> "new" approach by Mark was being discussed, doing the synchronization
> with an UPDATE message.

It was obvious when UPDATE was being developed.

What was hard was getting past the stupid reaction that sending a
UPDATE request to a Registry controlled devices violates the RRR
arrangments even if the change is authorised by the Registrar as
it is the Registrant communicating the the Registry.  Guess what
every time the Registrant does a DNS lookup in the Registry zone
it is talking directly with the Registry.

All the scraping etc. is a reaction to that.

> First of all, Mark's approach is not new, this has already been
> discussed in 2010 [1] [2]. At that time, people thought this would not
> fit in the traditional RRR model, but I feel that consensus has shifted
> now, probably because the use cases became more clear (thanks Paul!) [3]
> [4].
> 
> Also, back then there was more merit for a pull strategy (like CDS) than
> a push strategy, mainly because of scaling concerns with the push strategy.
> 
> I am very much in favor of having CSYNC to announce what RRtypes to
> synchronize and use CDS (or CDNSKEY) to announce the data for Delegation
> Signer synchronization. CSYNC only is not enough for DS/DNSKEY
> synchronization:
> 
> 1.
> CSYNC's way of doing DS/DNSKEY synchronization is complex. That is
> because there are many corner cases. I like simple. CDS is simple ("copy
> this"). Now that might not be a good reason for having a separate
> solution for DS/DNSKEY syncing. Or maybe it is? Anyway, there's more:
> 
> 2.
> CSYNC cannot handle the use case where the child announces the digest
> algorithm (what CSYNC can do is announce that there is a CDS (or
> CDNSKEY) record that needs to be dealt with).
> 
> 3.
> With CDS, you can support all kinds of rollovers, like Double-DS
> (pre-publish DS, swap DNSKEY if old DS RRset has expired from all
> caches). How would you do Double-DS with CSYNC only?
> 
> 4.
> Last but not least, I really appreciate the argument that Joe Abley made
> yesterday: with CDS it is very clear what the intentions of the child
> zone are, providing a sort of audit-trail that can be used for example
> for monitoring (sorry if I misquote you, I don't remember your exact
> words, it was quite late in my time zone). This is something CSYNC also
> cannot do without additional RRtypes.
> 
> 
> I hope this helps in understanding why we have CSYNC and CDS (not one or
> the other).
> 
> Best regards,
>   Matthijs
> 
> 
> [1] http://datatracker.ietf.org/doc/draft-mekking-dnsop-auto-cpsync/
> [2] http://tools.ietf.org/wg/dnsop/minutes?item=minutes78.html
> [3]
> http://datatracker.ietf.org/doc/draft-wouters-dnsop-secure-update-use-cases/
> [4] http://tools.ietf.org/wg/dnsop/minutes?item=minutes-84-dnsop.html
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]