Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02

"Wessels, Duane" <dwessels@verisign.com> Wed, 18 July 2018 18:36 UTC

Return-Path: <dwessels@verisign.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 E90DE130F62 for <dnsop@ietfa.amsl.com>; Wed, 18 Jul 2018 11:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 7l2snzW90naz for <dnsop@ietfa.amsl.com>; Wed, 18 Jul 2018 11:36:42 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 09FA2130F5E for <dnsop@ietf.org>; Wed, 18 Jul 2018 11:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9011; q=dns/txt; s=VRSN; t=1531939002; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=nGUbtvR3whE632Iggv9ZItGHe+RMSgg4wmdCIlcLZhI=; b=GPtYdISC55bX9u78Wre6z5PxABnAOEGty2DdifuwnkYRBqd0o9MCiJyp ALpTIZ9t1XPnWFp0HHovHQIbCzEcK0H4Rc0rK3nFx3wkWaSl71YXvSuNa 3CTxaFdZwisH2N1W5xePvwAtJ9QwBKIcNsPGl7vgVcuEpnJoO0snmcwuC LqVDzQk1axefmyenpWtJk0YhJf/+e7jfad3RDDLLUxZAeA+J3787Z2u+h TImYV/1GJAH2AgA4U7tAchfRxShsihoaSsYuHQmdx0WN6XhageLQhlZX7 mGE/LaJWD3IVx1S1ZR1CWl7ozJcIyWYPIVSkzn/23GT7YA7jJ6+Hrqjdr w==;
X-IronPort-AV: E=Sophos; i="5.51,371,1526342400"; d="p7s'?scan'208"; a="7212897"
IronPort-PHdr: 9a23:fVK2NRDSzkYUx1E9EszRUyQJP3N1i/DPJgcQr6AfoPdwSPX8r8bcNUDSrc9gkEXOFd2Cra4c1ayO6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglUhTexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iScHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRsZfWTJcDIOgYYUBDOQBMuRZr4bhqFQDthS+CRWpBO711jNEmmH60Ksn2OohCwHG2wkgEsoAvHvUstr1L7wSXv6xzKnT1TnIcv1Y2Srn54jObB8tr+yHULVtfsvf10YvDBjFgUuUqYz+JD6VyPoCs3Ka7+p7VOKvhGgnpxttrTiow8chk4/EjZ8bxFDD8CV22oc1JdugRU50YN6kDJtQtzyBOIdsXswiRGRotSAnwbMFoZ62ZDUGxIg9yxLCafGKfZKE7g/jWeufOzt1i3FodKqiixqu60Ss1+/xWtWu3FpXoSdIkcPAum0O2hDL5MiIVPhw8luk1DuKzQ/e6eVJLlsxmKfVNZIu3789m58IvknHHyL7mkD7gaGYe0gm5+el7fnsbK/8qZ+GLYB0jxnzMqEpmsOiH+s1KhMOX22H+eSk073j4FH5TK1KjvIolqnZt4jXKNkHqKChHgNa0p4t5Rm+ADu6zdgUh2cHI05CeBKdl4jlIUvBL+3iAfehmVSsizFry+raMb3mB5XBNnnDkLH/crZh80NQ1RY/wcpC659WBLwNOu//V0//udDCARI0MBS4w+P9B9V80oMeV3iPAqicMK7KrFCJ6PwgI/KXZIALvDb9MOMo5+Dwgn8jmF8dZqip3ZQRaHyiAvtmJECZbWL2gtgdCWcKohY+TOvyhV2ZUT5cfXCyULwn6zEnCYKmCJnMSpmxgLybxii7AINZZmRCCl+SC3fobJ+IW/AWaCKdOsVhiCALVaC9S4890hGjrBL1y7x8LurT4i0VrpPj28Zp5+3djx0y8iZ0D8vOm12KGlp0l2UFDxw7xro39Vd9w1GO+bR5hvEdCcZa+f5NVgogLtjb1eMsWP7oXQeUNOiEU02rRs7iSR0sR9Q8iZdab1lwAM6vigvrwSewAqQUmLrND5sxpPGPl0PtLtpwni6VnJIqiEMrF44WbTWr
X-IPAS-Result: A2GBAQBOh09b/zCZrQpcGgEBAQEBAgEBAQEIAQEBAYQsgScKmgwklTmBPzsIAyMLhD4Cgxs1FwECAQEBAQEBAgEBAoEFDII1JAEKBEs6MAEBAQEBAQEBAQEBAQEBARoCDWMBAQEBAgF5BQsCAQgYIwsCMCUCBA4FDoMSAYF3F6sfij0KBYpaPoE4DIJegUGBTAwChRKCJAKHbYoHh2wDBgKDW4FZVIkrgTaEEYgRijuHNQIEAgQFAhSBQgGCCXAVZQGCPoIxHIM0ilJvikQrgQGBGgEB
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Wed, 18 Jul 2018 14:36:40 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1466.003; Wed, 18 Jul 2018 14:36:40 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Shane Kerr <shane@time-travellers.org>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
Thread-Index: AQHUHGsFkfdLLiFUM0KZSCgbZhElpqSVlrqA
Date: Wed, 18 Jul 2018 18:36:40 +0000
Message-ID: <E92190FF-6520-428C-B5D6-37E8175D1EE9@verisign.com>
References: <3e5675e4-3ae0-f21c-7e3a-e9214953888e@time-travellers.org>
In-Reply-To: <3e5675e4-3ae0-f21c-7e3a-e9214953888e@time-travellers.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_2DAA6F14-849A-4EA1-A463-8905EE5E227A"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/axC6RQ1qxeZSzenIrgfdSGDQYWU>
Subject: Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 18 Jul 2018 18:36:45 -0000

> On Jul 15, 2018, at 11:37 AM, Shane Kerr <shane@time-travellers.org> wrote:
> 
> Bonjour,
> 
> I decided to implement draft-wessels-dns-zone-digest-02 at the IETF 102 Hackathon. As expected, it is fairly straightforward. You can see the code on GitHub:
> 
> https://github.com/shane-kerr/ZoneDigestHackathon

Thanks Shane!


> It seems to work, although since I have no other implementation to compare against I can't be sure that the digest values are in any way correct.

My own implementation, alluded to in the draft, is here:

https://github.com/verisign/draft-dns-zone-digest/tree/master/impl

I have a few test cases in the Tests directory.

> 
> In proper hackathon style there are no tests. Bugs surely abound. If you use it in production please keep a fire extinguisher handy.
> 
> I found the draft to be clear and fairly complete, although I have a few suggestions:
> 
> * It might be worth mentioning that names are expected to be
>  uncompressed. It's kind of obvious, but it might trick up some
>  implementations.

The draft says "It also adopts DNSSEC's canonical RR form (Section 6.2 of [RFC4034])" in one place and "calculated by concatenating the canonical on-the-wire form of all RRs" later.  I wouldn't object to being more explicit.  Do you want to propose some text or shall I take a stab?

> 
> * The TTL of the ZONEMD record has to come from somewhere. It can either
>  come from configuration or pulled from somewhere else (I used the TTL
>  of the SOA record). This should be documented.

I also used the SOA TTL in my implementation.  I can make that a recommendation in the draft.

> 
> * It might be worthwhile giving some recommendations or even
>  requirements about what to do with failures. For example, something
>  like "secondary servers who receive a zone that fails a digest
>  validation SHOULD NOT serve the zone".

Happy to add something like that.

> 
> * Having some example zones and the expected digest values would be very
>  useful for implementers.

Agreed.  I would like to have some examples as an appendix in the document.

DW