IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

Mark Andrews <marka@isc.org> Mon, 20 May 2019 23:08 UTC

Return-Path: <marka@isc.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 AD30012008D for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 16:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WMhQpse6O0ao for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 16:08:45 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 23848120046 for <dnsop@ietf.org>; Mon, 20 May 2019 16:08:43 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5B2B03AB03F; Mon, 20 May 2019 23:08:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 405AB160079; Mon, 20 May 2019 23:08:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2805A160077; Mon, 20 May 2019 23:08:41 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KeJbDhG_Z5h6; Mon, 20 May 2019 23:08:41 +0000 (UTC)
Received: from [10.9.131.87] (unknown [120.17.165.87]) by zmx1.isc.org (Postfix) with ESMTPSA id A5914160076; Mon, 20 May 2019 23:08:40 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <CBFC1866-EDC7-4639-BD01-75B17F8FE7E4@verisign.com>
Date: Tue, 21 May 2019 09:08:37 +1000
Cc: Olli Vanhoja <olli@zeit.co>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <83948DCF-1855-4DC2-ABB7-C50EFBFFED7F@isc.org>
References: <155009468256.9559.12509906855495134896@ietfa.amsl.com> <923006F8-EB5A-4098-81A2-782BC90BF220@verisign.com> <CAAiTEH_GmvNVgAZzwG+oaQrtNd_b=kpDSRz7ErbmTjuXrzziWg@mail.gmail.com> <CABrJZ5FBYpFrjpm-a+B9FF8rbVNXwy=V-MP0TPS8fG87OJeteg@mail.gmail.com> <0E8CD2BB-C8C6-4387-8FAD-DAC84B381557@verisign.com> <CABrJZ5GBrFFqW8cnHAfM07jb1nE79TeW97nCODxtpMPVDqy1Bg@mail.gmail.com> <CBFC1866-EDC7-4639-BD01-75B17F8FE7E4@verisign.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_r98nWDeQ5ZBZMK7oLVNijl3dhc>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 20 May 2019 23:08:47 -0000

I think the worry is that some name servers may normalise the text format when loading from disk. The slave would then have a different wire format. 

Such servers are broken. Wire to text to wire should produce the same rdata bit pattern with the exception of the types which are known to be compressible. 

-- 
Mark Andrews

> On 21 May 2019, at 08:26, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org> wrote:
> 
> 
>> On May 17, 2019, at 12:14 PM, Olli Vanhoja <olli@zeit.co> wrote:
>> 
>> I believe this has been in a bit stall for some time. I'm finally
>> trying push for some real production implementations.
>> 
>> I have one note that I wrote when I was initially reading the draft:
>> 
>> - Canonical RR Form comes from RFC 4034 s. 6.2 and it doesn't require
>> require normalization of SPF and CAA records. RFC 6844 specifically
>> allows any string formatting allowed by
>> https://tools.ietf.org/html/rfc1035#section-5.1
>> 
>> Not sure if there is any real issue with this one but in theory I
>> guess there could be functionally equivalent records with a digest
>> mismatch. Maybe it's even desirable that those are not normalized,
>> just a note.
> 
> Hi Olli,
> 
> Can you expand on this?  I'm not sure that I follow.  
> 
> ZONEMD doesn't operate on presentation format of RRs.  It only operates on canonical wire format.  Are you saying that some RRs can have different valid wire formats?  That would surprise me since DNSSEC signatures are also based on that format.
> 
> DW
> 
>

v2.23.0 | Report a Bug | By Email