Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Shane Kerr <shane@time-travellers.org> Thu, 21 June 2018 20:09 UTC

Return-Path: <shane@time-travellers.org>
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 46606130DDA for <dnsop@ietfa.amsl.com>; Thu, 21 Jun 2018 13:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcnniEn5ksiA for <dnsop@ietfa.amsl.com>; Thu, 21 Jun 2018 13:09:07 -0700 (PDT)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0206C12777C for <dnsop@ietf.org>; Thu, 21 Jun 2018 13:09:07 -0700 (PDT)
Received: from 001-209-128-083.dynamic.caiway.nl ([83.128.209.1] helo=[172.29.2.99]) by time-travellers.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1fW5uv-0005dN-7N for dnsop@ietf.org; Thu, 21 Jun 2018 20:10:53 +0000
From: Shane Kerr <shane@time-travellers.org>
To: dnsop@ietf.org
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <27C44216-581A-4991-A739-ECE8B7F8AA35@verisign.com> <884c2d11-9db0-7668-59c9-baa8574a03f7@time-travellers.org> <37873808-8354-b26b-34f4-880ea7a5f0da@nic.cz>
Message-ID: <e9f99fce-c240-7f23-c580-1fb8bd0a0687@time-travellers.org>
Date: Thu, 21 Jun 2018 22:09:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <37873808-8354-b26b-34f4-880ea7a5f0da@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RTNwJ_xdi_CKWBzcWSD9CkhA0ig>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 21 Jun 2018 20:09:09 -0000

Petr,

Petr Špaček:
> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
>> Wessels, Duane:
>>>
>>>> On May 25, 2018, at 11:33 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:
>>>>
>>>> At Wed, 23 May 2018 15:32:11 +0000,
>>>> "Weinberg, Matt" <mweinberg=40verisign.com@dmarc.ietf.org> wrote:
>>>>
>>>>> We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note,
>>>> this -01 version includes the following changes:
>>>> [...]
>>>>> We plan to ask for time on the dnsop agenda in Montreal.  Your
>>>>> feedback
>>>> is welcome and appreciated.
>>>>
>>>> I've read the draft.  I have a few high level comments and specific
>>>> feedback on the draft content:
>>>>
>>>> - It was not really clear exactly what kind of problem this digest
>>>>    tries to solve, especially given that the primarily intended usage
>>>>    is for the root zone, which is DNSSEC-signed with NSEC.
>>>
>>> Thanks you for the feedback.  We will write a clearer problem statement
>>> in the introduction for the next version.
>>
>> As I mentioned, I have seen zones broken during transfer in production,
>> and having a standard way to check for this seems reasonable.
> 
> Hmm, can you share some details about your experience?
> Did you find out when the data corruption took place?
> a) network transfer
> b) implementation bugs (e.g. incorrectly received IXFR)
> c) on disk
> d) some other option?

I don't know. I have seen incorrectly transferred zone files both in 
BIND and NSD slaves. IIRC our solution was to include sentinel records 
in the zone files to spot problems, take the node out of service, and 
force a re-transfer. This of course won't work if you are slaving zones 
that you do not control, and it doesn't prevent a small window of time 
when the servers are operating with broken zones. TSIG was being used.

Another scenario is when you are not using TSIG at all. For my own zones
I don't bother because I don't have any confidential data in them and I
prefer the operational simplicity of not having to set up keys 
everywhere. But this may also be the case for things like the root zone 
where the zone publishers explicitly want people to be able to transfer 
the zones without authentication.

> I wonder if this proposal is worth the complexity ... If we wanted plain
> checksum we could use TSIG with built-in key (all zeroes or so) and to
> get checksum for the network part with negligible implementation
> complexity. (TSIG trick is Mukund's idea, not mine

I kind of like this approach. It doesn't provide any help for 
stand-alone zone files, but in general there is no interoperability 
requirement there and a simple sha256sum file is probably good enough.

Instead of zone digest maybe it makes sense to document Mukund's 
approach in an informational (?) RFC? It still doesn't solve problems 
where something on the receiving side doesn't work due to an 
implementation bug, but I'm basically okay with the recommendation being 
"don't run software that doesn't work". 😉

Cheers,

--
Shane