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

Michael StJohns <> Wed, 08 January 2020 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E685C12012A for <>; Wed, 8 Jan 2020 11:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT2=0.1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2amm8f45KQ40 for <>; Wed, 8 Jan 2020 11:38:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B2C912011B for <>; Wed, 8 Jan 2020 11:38:25 -0800 (PST)
Received: by with SMTP id c16so3751908qko.6 for <>; Wed, 08 Jan 2020 11:38:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=VwtFkUmpL/QIxjPwP1vlUNinpKcL5XVju1moAmXkRe0=; b=1dz/Z6WljEV6dI8A8z5EisZj3RvS71DXuwR9Skn6Wyqo0WoAAzr3mmY8PjPCdNfZGY FZo5VAjAMAH+oIYwVHtRoGbezHMYGabZff9nh+hRKzgkTm1DvD+EMQ6QGJ1Tpxn/U/51 M6hCIS5cgMt8gBxtlHSQzX7cIsDHfw4ofWO9HBclEDBeeXKerLDMnXp23DscLR4NZvMa Go/RhRRmuSCgEsk/t1MkZ4nY0seSnVQmVnyfWr2T6hBAWpOANxPKXAwwDFhOx06sP5AL sZIPByU5YH6xBJY9tf6GKKrLoMAQHyC/fJ6sX9qJZpkiziX1vqEVZUjPnoqD7n1GKpkc AkZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=VwtFkUmpL/QIxjPwP1vlUNinpKcL5XVju1moAmXkRe0=; b=WaL481uWbyGfn9yxxNirrJLYbc9CGSO6Gu+TVmKMGHJw1LzHxFEK0gDrppc5LFanJU WFhcgHNUEvvySyj56PWhYDpXhlWRzOtMtzXMJMWuhMBvPX2+lRXQUr6oJU/1xrmlaZ0q I94r7fJyLX6hIfwAjRqinXQVnS7+gfy0rQjPH8ivv7oSMfmvEKPqD4yvFXhLr1L/Vkt2 Y6v6qndWHXA7lOTdY0wEtX1a6yEBmfWTTz/vIaKswSneddTF8KlBqlgOQ7xK8UsW8tcH SBOCItJcdtAWZ958YMxcYKMcMn4gxatb6WGAly0A24gZY9mQgvKlEMrSC6upHhdfVpj5 yZ4A==
X-Gm-Message-State: APjAAAXK8OyRDQFN99RKyNAT1DV/gVO929G0NoXnwHiHAN5kpY8JPLrb kxEqD5aGqbE2tV2l0cORQwx8zVAZDX4=
X-Google-Smtp-Source: APXvYqyy0AyWwzwvMGYANdF2tg/7i2fMfv1SvDxud0QJWk7zrLvmYO4AoLSeXUb/XLncFALLmuKQ8A==
X-Received: by 2002:a37:4dc4:: with SMTP id a187mr6103277qkb.436.1578512304503; Wed, 08 Jan 2020 11:38:24 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:dd4:4ade:7d8:f573? ([2601:152:4400:437c:dd4:4ade:7d8:f573]) by with ESMTPSA id l17sm1895827qkk.22.2020. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 11:38:24 -0800 (PST)
References: <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 8 Jan 2020 14:38:23 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] [Ext] 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: Wed, 08 Jan 2020 19:38:27 -0000

On 1/7/2020 10:05 PM, Brian Dickson wrote:
> My $0.02 on the size issue:
> I think the onus should be on whoever is publishing a zone with a 
> ZONEMD to provide guidance on what to do if a failure occurs.
> Similarly, publishers should be sensible on whether to include a 
> ZONEMD based on total size and rate of change.
Then there should be some sort of signalling mechanism WITHIN DNS that 
allows a consumer to figure out what to do when the failure occurs - if 
that is going to be a per-zone case.  Perhaps a field in ZONEMD?

What you're suggesting somewhat has the conclusion that this will never 
be useful in general purpose zones, because the consumers of those zones 
would have to have a back channel path to find out the guidance for 
potentially large numbers of zones.

Later, Mike