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.
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
