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

Olafur Gudmundsson <ogud@ogud.com> Mon, 09 July 2018 03:39 UTC

Return-Path: <ogud@ogud.com>
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 C5620130EF7 for <dnsop@ietfa.amsl.com>; Sun, 8 Jul 2018 20:39:43 -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, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 odhS7nNr3C1K for <dnsop@ietfa.amsl.com>; Sun, 8 Jul 2018 20:39:41 -0700 (PDT)
Received: from smtp117.ord1d.emailsrvr.com (smtp117.ord1d.emailsrvr.com [184.106.54.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E88130E0E for <dnsop@ietf.org>; Sun, 8 Jul 2018 20:39:41 -0700 (PDT)
Received: from smtp15.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp15.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id CE50B60172; Sun, 8 Jul 2018 23:39:40 -0400 (EDT)
X-Auth-ID: ogud@ogud.com
Received: by smtp15.relay.ord1d.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 92FC260138; Sun, 8 Jul 2018 23:39:40 -0400 (EDT)
X-Sender-Id: ogud@ogud.com
Received: from [10.20.30.43] (pool-71-191-91-81.washdc.fios.verizon.net [71.191.91.81]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Sun, 08 Jul 2018 23:39:40 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <C49D48FA-0200-4C21-9C07-69CD2CE9447A@isc.org>
Date: Sun, 08 Jul 2018 23:39:39 -0400
Cc: Petr Spacek <petr.spacek@nic.cz>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B539303-049A-4305-8D36-862092713DB4@ogud.com>
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> <e9f99fce-c240-7f23-c580-1fb8bd0a0687@time-travellers.org> <20180621203116.a7kv4ysotfe7kw5k@nic.cl> <3ba53c28-8895-b0ec-badc-7ce31a8df8fc@nic.cz> <C027F687-BE37-42D4-959B-269BA2F49837@ogud.com> <C49D48FA-0200-4C21-9C07-69CD2CE9447A@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nicsgGOi5GFeeusDE3r-Blu4tF8>
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: Mon, 09 Jul 2018 03:39:44 -0000


> On Jul 8, 2018, at 9:35 PM, Mark Andrews <marka@isc.org> wrote:
> 
> So what if it is not feasible for COM and similarly sized zones?
> 
> At the moment we have one zone where we need a zone signature so that the zone contents can be loaded into every recursive server.
> 
> The question we should be asking is "Is SIG(AXFR) a good fit for the root zone?” not whether is is a good mechanism for all zones because quite frankly there are very few zones that you would want loaded into all recursive servers.
> 
> “.”, “arpa”, “in-addr.arpa” and “ip6.arpa” would be about it.  Does anyone else have any others?  Any zone would necessarily be small. 
> 
> Mark

So the followup question is 
Should we burden the Auth Server implementations with this calculation if the usage case if 4 zones ? 
or is this better handled by external tools ?
DNS Camel says ? 

Olafur

>> On 9 Jul 2018, at 10:28 am, Olafur Gudmundsson <ogud@ogud.com> wrote:
>> 
>> 
>> 
>>> On Jun 22, 2018, at 6:58 AM, Petr Špaček <petr.spacek@nic.cz> wrote:
>>> 
>>> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote:
>>>> On 22:09 21/06, Shane Kerr wrote:
>>>>>> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
>>>>>> 
>>>>>> 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.
>>>> 
>>>> We have also seen broken transfers between secondaries. Our solution
>>>> is to dump the zone after transfer, calculate a hash and compare. We
>>>> would benefit from having a ZONEMD record inside the zone.
>>> 
>>> If the zone got broken during TSIG-secured transfer then it was not most
>>> probably not caused by network problem because TSIG would have caught that.
>>> 
>>> Honestly I do not think it is worth the effort because all the
>>> complexity does not help to prevent implementation bugs, I would say it
>>> even increases probability of a bug!
>>> 
>>> What is left is bug on auth and/or slave sides and in that case there is
>>> no guarantee that
>>> a) master did not compute ZONEMD from already broken data
>>> b) slave verification of ZONEMD actually works
>>> 
>>> 
>>> If we wanted to catch problems with implementation we need something
>>> which is outside of the DNS stack we are attempting to check, be is
>>> simple checksum or some fancier crypto.
>>> 
>>> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
>>> node and an utility which would extract OPENPGPKEY RR from the zone file
>>> and verify that the zone file signature (either detached or in .gpg
>>> file) can be verified using that key (+ add DNSSEC into the mix if you
>>> wish).
>>> 
>>> -- 
>>> Petr Špaček  @  CZ.NIC
>>> 
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> 
>> 
>> +1 
>> I spent lots of time earlier this century along with Johan Ihren trying to figure out how to 
>> secure the transfer of a particular zone (the root) to any resolver. 
>> The only sane way is to not transfer the zone over AXFR as any intermediary can mess with the zone contents mostly in the case of “glue” records,
>> thus transferring the zone over HTTPS or RSYNC with a PGP signature over the zone file is the only viable solution going forward. 
>> 
>> 
>> Historical background: SIG(AXFR) was rejected because it required putting the zone into canonical order and calculating the signature, 
>> in the case of dynamic update this is a real expensive operation, thus we got rid of it. 
>> 
>> Olafur
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>