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

Matthijs Mekking <matthijs@nlnetlabs.nl> Wed, 06 November 2013 10:19 UTC

Return-Path: <matthijs@nlnetlabs.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D19521E8088 for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2013 02:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkfyxfCrH900 for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2013 02:19:22 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E72321E80AD for <dnsop@ietf.org>; Wed, 6 Nov 2013 02:19:21 -0800 (PST)
Received: from [IPv6:2001:981:19be:1:2199:567d:4fe9:79d9] ([IPv6:2001:981:19be:1:2199:567d:4fe9:79d9]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id rA6AJI3N071713 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <dnsop@ietf.org>; Wed, 6 Nov 2013 11:19:19 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl)
Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl rA6AJI3N071713
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1383733160; bh=YksGrjTVNgZzDUCDk91h/TH/u29YR/8J8M/2UuZyZ6A=; h=Date:From:To:Subject; b=vX/KRXvCEeTKcUvNIBM2Cnn0FaOjuXVveHc6NFncYNxn65eN38Z16Pe/DYuKPB8W0 fz0CB1O4kq1WJqIS1iQ88Buek4Hezs0eJfEq9P8E/colEau5aD3i97Q+2kMar86zW3 RBWvJ7UdCFYp+maEVVVZzKLQ3gbKb506ZcIe3tvY=
Message-ID: <527A17A6.3050400@nlnetlabs.nl>
Date: Wed, 06 Nov 2013 11:19:18 +0100
From: Matthijs Mekking <matthijs@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: 'IETF DNSOP WG' <dnsop@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Wed, 06 Nov 2013 11:19:19 +0100 (CET)
Subject: [DNSOP] CSYNC. Or CDS. Or something completely different.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 10:19:23 -0000

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