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

Brian Dickson <> Wed, 08 January 2020 03:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E010812002E; Tue, 7 Jan 2020 19:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GNgd-Xm_VzXz; Tue, 7 Jan 2020 19:05:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8CB51200EB; Tue, 7 Jan 2020 19:05:42 -0800 (PST)
Received: by with SMTP id p6so926743vsj.11; Tue, 07 Jan 2020 19:05:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UvGtvkLxXLKQCGaHsy2v/oOaHfKXH8gAnzJ9FqcB/hg=; b=FHUs0COHmKI2wQl3UbqV1Pdy0puERRNUeQstKPHWf77hYpCZMAa9HkV540N47qvXV4 ykBIOAg+RYRn+gYTKYS8pj+kUO3yTziexPZgL5gTtU8j9jd1jfJYdQfUAGbMe+tBw0Pf /gl9Bdw493XbzWE2pXFRoQJshphQQKeEoEHZxVKf46NygZV8F+oS7dBQGcEbLOAkpjKQ p0pULeNnZgKGyRfoSIZd5xlKvvU7PAS/pvztopEV1E/wunbgZs0ctXIDkBNSGvkhqjOO aOhu5u2e8D+Cl5iQl/iFIiZDdX1QdRdVKTZplYOXIY7wRYl1820vODB+k6wZcZm0YNuY lr3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UvGtvkLxXLKQCGaHsy2v/oOaHfKXH8gAnzJ9FqcB/hg=; b=OrCvtsU9vpF5+cxb8msRLzvEWw9hWRx5B0ivzLjsIIqRFBtrjSYTDq5PC1qb/J2N0V 3L8YOMmWdQnJJaLz/K+CexrgqNRPcvHWECGj7tbfZIQGjunZ3AgJ54V3Gz6FkLBZt459 DaFIV5ZwhB4AZg7Rv5tPn5nGNEVUDlcyilAmTwMsK7/bDct3VhaF7Jv9yjqfnfbuPFyv 5upFt07kpFhXdFMlxobTeR2d7BGgCNHyW8CBlkoKschaSsDEUVZYEhEYmNUThyA9cynz Pm7g+T0FprF2+O0X2wfQflnn4/5PjcBhPMpG53WtMPcI92uDJeNU/1qlr7SUjIRpaiRj a2/Q==
X-Gm-Message-State: APjAAAU9w72cvq9KGsX4PgJqGXhOURn8XRbdAyIUlFvVUSMDFz563cKW y//JBnfuPfF+r0hHK5vvp7mT/W4DKGRKQP4XfgUEsg==
X-Google-Smtp-Source: APXvYqyfJbYK4OlEuvXI+8RyXYDB3XYUbQo1BkrXVX8kr7caPErZC3hdVNuPcSqC3nKgOZfF9HL6fZJwVub5QCp3K3I=
X-Received: by 2002:a67:fb14:: with SMTP id d20mr1500499vsr.136.1578452741932; Tue, 07 Jan 2020 19:05:41 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 7 Jan 2020 19:05:30 -0800
Message-ID: <>
To: Paul Hoffman <>
Cc: dnsop <>, dnsop-chairs <>
Content-Type: multipart/alternative; boundary="000000000000fa4ff1059b982abd"
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 03:05:45 -0000

On Tue, Jan 7, 2020 at 6:18 PM Paul Hoffman <> wrote:

> On Jan 7, 2020, at 6:03 PM, Joe Abley <> wrote:
> > I don't object to the intended status (standards track). There are
> reports of multiple independent implementations included in the document,
> which seems pleasing and proper.
> Definitely proper. The calls for making this RFC "experimental" go against
> the definition for that designation in RFC 2026, Section 4.2.1.

While I think the WG list has been rather quiet on this draft, I think it
is probably best to wait for more responses either way regarding
"experimental" vs "proposed standard".

(ibid) section 4.1 and 4.1.1 does make reference to the maturity level of
standards track documents, and includes the possibility of changes or even
subsequent withdrawal of a standard based on experience.

I concur with Joe, in that the document seems pretty clear, and I support
moving it forward in the standards track.

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.

The onus is on operators to operate their infrastructure with appropriate
levels of caution.
Blindly turning on processing of ZONEMD on zones from random senders might
not be wise.