Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

Miek Gieben <> Tue, 14 January 2020 06:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCD4712004E for <>; Mon, 13 Jan 2020 22:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T9Zw379gCxsM for <>; Mon, 13 Jan 2020 22:15:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88F27120045 for <>; Mon, 13 Jan 2020 22:15:45 -0800 (PST)
Received: by with SMTP id m24so12348725wmc.3 for <>; Mon, 13 Jan 2020 22:15:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Pfj/6CPRF0A0zX6bGMvuKqWuWLl9rKff1wC40fge+KQ=; b=SJfrRAh6bi4OTnfPuuMDxKJIRDuzY1PLqvVHXWPOKeWhIKcimgWlyUSd9081+Bi8hN 8KW8l3sbgNZCKRE60u0dE2zvXpZcqVszgMR27jFArUe52eGYn/Gr1TdRw869FI88rt+M gimAj9zfTtaXMZAHpY98v9QjFc2b0guff29cusv+PvhA0SYLMOejm2XvQwMXaSGzAVkp Xt9IuoVe4SwH1/dyZmxvde50IRpM8RzmVfc3+ciT9J6/DSHllSA309SFe4ZbClifdBUh 7RMOfboBiWyax/vAyQVzla8y1PPMesjeocTvQhjg/UyYaODu/wckVzXfxpb12OkRLaEY 3ZTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=Pfj/6CPRF0A0zX6bGMvuKqWuWLl9rKff1wC40fge+KQ=; b=MYXeTS68wWQVS8g01VOofbrqG9npuGBFPiiLlY8XZ53dPo1FvE1ti59rKq4n+q7hDv E5/TKqTAv2HYw2iGXiN2nlRc2aRph2kdRNGDK1/MixmJCXLF6LP1Bkds1hqdDpoavv7a RA1OHPAta8xKhLVnu/hMFuRyt6G3aGKt2gTvd7cO2JTujtbMf9s9g60jSndCu2Ifj4hb 1xvdumN4nAsWlXaRk0WFHZMGZnVMW24UjHM9/fu2oI2Ai1x8BHGSuzLOECADLhci9Rwo e3nEp8dgdOKNouIRajdjiBBwBuLJZMGTJB3YBx4feu0POqGBeORggCIrg80sM4JQdLBW +dhw==
X-Gm-Message-State: APjAAAX69HWkdwYWiDL3GnH4Db8Ynii+0UbkELEQsJMJXQcSTzmaXmDh C0+C1yZzzpI6lsmwz3YA4QrMI/OpBxOWFg==
X-Google-Smtp-Source: APXvYqwITh1mK/u3HXPz72j9tf4Z9kh2Vm26zWsutdRSh/rvb+x1IfSgRUrwVSet9AyVJKAJZjRDyA==
X-Received: by 2002:a7b:c4c3:: with SMTP id g3mr23784093wmk.131.1578982543921; Mon, 13 Jan 2020 22:15:43 -0800 (PST)
Received: from ([2a02:a450:f343:0:358f:eb20:57aa:baf1]) by with ESMTPSA id i11sm18533498wrs.10.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2020 22:15:43 -0800 (PST)
Date: Tue, 14 Jan 2020 07:15:38 +0100
From: Miek Gieben <>
To: Michael StJohns <>
Cc: John R Levine <>,
Message-ID: <>
Mail-Followup-To: Michael StJohns <>, John R Levine <>,
References: <20200107023630.628251208AAF@ary.qy> <> <alpine.OSX.2.21.99999.374.2001081359350.85317@ary.qy> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jan 2020 06:15:48 -0000

[ Quoting <> in "Re: [DNSOP] Working Group Last Call..." ]
>I'm not convinced of the general utility of this scheme. 
>It feels like DNS bloat and more a solution in search of a problem.  
>That said, I appreciate  Duane's willingness to make changes to fix
>some of the more egregious problems.

I like to echo this sentiment; esp considering this draft is heading towards a standards

Also the example given in 1.1 Motivation is a bit weak:

"For example, a name server loading saved zone data upon restart cannot guarantee that the
on-disk data has not been modified.  For these reasons, it is preferable to secure the
data itself."

That looks like an implementation detail for nameservers loading the zone, not something
the IETF should fix.


Miek Gieben