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

Shane Kerr <shane@time-travellers.org> Thu, 19 July 2018 14:26 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 BF4371310F0 for <dnsop@ietfa.amsl.com>; Thu, 19 Jul 2018 07:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 zJ2ZMCG8XNMm for <dnsop@ietfa.amsl.com>; Thu, 19 Jul 2018 07:26:21 -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 67775130F13 for <dnsop@ietf.org>; Thu, 19 Jul 2018 07:26:18 -0700 (PDT)
Received: from [2001:67c:370:128:72e7:8f03:3ad9:63f1] 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 1fg9up-0007ML-EM for dnsop@ietf.org; Thu, 19 Jul 2018 14:28:23 +0000
To: dnsop@ietf.org
References: <3e5675e4-3ae0-f21c-7e3a-e9214953888e@time-travellers.org> <E92190FF-6520-428C-B5D6-37E8175D1EE9@verisign.com>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <c8c2b792-3a1c-0252-ba86-6cca10be7680@time-travellers.org>
Date: Thu, 19 Jul 2018 10:26:13 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <E92190FF-6520-428C-B5D6-37E8175D1EE9@verisign.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8jfT9k8V86Jv4KQqvlp4huRf1AI>
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: Thu, 19 Jul 2018 14:26:34 -0000

All,

On 2018-07-18 14:36, Wessels, Duane wrote:
> 
>> 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.

Duane sent me a mail off-list and after minor tweaks on both sides it 
seems like the two implementations now interoperate.

>> * 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?

I think just adding like this is enough:

"calculated by concatenating the canonical on-the-wire form, without 
name compression, of all RRs"

>> * 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.

Someone pointed out to me that since ZONEMD is meta-data we don't really 
expect it to be queried normally, and a TTL of 0 is a reasonable default.

My own feeling is that I would like ZONEMD to be a "normal" record 
outside of zone generation, so assume that it can and will be queried 
just like any other record. (This is also an open question in the 
current draft, IIRC.)

In the current draft we already have to look at the SOA to get the 
serial, so using the TTL is straightforward. If we remove serial from 
the ZONEMD then TTL from the SOA might be less obvious, but I think it 
will still be the best default.

Cheers,

--
Shane