Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt

Brian Dickson <> Thu, 01 November 2018 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71651127333 for <>; Thu, 1 Nov 2018 15:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_PASS=-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 v2gV_7t7uPrF for <>; Thu, 1 Nov 2018 15:30:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 006A412896A for <>; Thu, 1 Nov 2018 15:30:38 -0700 (PDT)
Received: by with SMTP id 124so17897vsp.12 for <>; Thu, 01 Nov 2018 15:30:38 -0700 (PDT)
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=0WupIfgQxKKlC2349C6bjKFAA0cmHGDJDY0JugwYBIM=; b=FdcL/mKqGFkO3mMEP3S7sE1gSP8AG6TKkT0Sn1IcIeq0mns1gJ1Z/ARcGqJOIj5VQJ 2Uk4/wYPS1zmHg5wt9xn5weyMpyuY50StpgPE8V72bYMqJGiP/qTSW7PbLNBJcKZGHMI QA0sOYFMN8WDrZ1tkqXujbDl8K4CE+67KEdgAAMpnZuzvWgkQwWZV3PKha3mzDqdUak7 kRvcMVlnCWVio2dbNidG6J7bcQOH4ISdDz1gpMJE35UZF2NNJBABKaC2rTse+eK/LBym /yO70Yocy8XqGM2vPtFmTA+uOt7kHxm4AVE5E0DInFU9zRLs8qxE3pZyoG2+/l7ieusd VdzA==
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=0WupIfgQxKKlC2349C6bjKFAA0cmHGDJDY0JugwYBIM=; b=I0gQfVRRP9pyhzxS2aq8SNsKYDQJTT+fFwzNtSy5msO2LG51/0xzFVYjnEywwX/vZK CS+YZraoI5ctq+I/+jeeV/a0PZi5QLEuWkSDUlWxBxlrZg0wq0M1NtazxeCy9imnTEez hb/fCFys0wgmFIHP0eQSBAco0YoZFzRQWEQuSIvF71MR20gflVlwLlpc/RxdE0re4bo3 3aAUza/U4RtXE5URLAzKfGyQ9tk3i4goEtZ+hITso7Cd5DNxpOd+U2LGsESbU9miRAQ9 o0+Wr/RDVllIWN+QPKVN//V3B+mDe8PYOkHCUJV4sGDLmo+l/cXIoDMS+63IhGaZewcU SaaQ==
X-Gm-Message-State: AGRZ1gLOC4V4k+lapHflgUMLJclzNlX1SKyoRsCcbU4RH0BhJSgIGGnX ODwDc9iJTBa3F3LWNDAxZ9S1uaLS/tYuQYJE5xw=
X-Google-Smtp-Source: AJdET5fJ+p6jox6y4VP2IZyk9WwSyMmwpdBcTlj5mgc9yEhjRmMtlvAhMwhm+oqSNN/94zVKjEhkTN2rMRHKM4b4sgM=
X-Received: by 2002:a67:6805:: with SMTP id d5-v6mr4104322vsc.199.1541111437977; Thu, 01 Nov 2018 15:30:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 01 Nov 2018 15:30:26 -0700
Message-ID: <>
To: Joe Abley <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="000000000000d1ef230579a1f75a"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt
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: Thu, 01 Nov 2018 22:30:43 -0000

On Thu, Nov 1, 2018 at 12:09 PM Joe Abley <> wrote:

> On 1 Nov 2018, at 15:06, Brian Dickson <>
> wrote:
> > Maybe signaling the algorithm(s) for which signature(s) are
> desired/understood would do the trick?
>> > I.e. in an EDNS option?
>> I don't think so. EDNS options relate to servers exchanging DNS messages.
>> ZONEMD relates to zones.
> Hmmm... so at best it would be a one-way signal from the client to the
> server, about what they support (and optionally prefer).
> The server has to send all the ZONEMD records regardless.
> There aren't necessarily any clients or servers, DNS or otherwise. A zone
> could be produced and consumed in some other way.
If it is still useful/interesting to measure algorithm support, it probably
makes sense to use methods that do that via the available mechanisms on
each of the "other way"s.

E.g. Pass similar parameters on algorithm support to http/https via the
'?VAR=VAL' component of a URI
This could possibly include:

   - Whether the client assumes all risk regarding algorithm support and
   provides no algorithm info?
   - If there is zero-overlap on algorithm support between client and
   published contents:
      - Does the client prefer HTTPS over HTTP if it is available? (Yes, it
      is safer, but some clients might not care, or even want https)
      - Does the client insist on HTTPS for transport instead? If the
      server does not do https, return 4xx in that case
      - Does the client allow HTTP transport as fall-back?
   - Whether the client does DNSSEC validation (if not, return only the
   unsigned stuff)
      - (Include the logic for HTTPS vs HTTP in the zero-overlap case)

For protocols that don't have the parameter passing capability of http's
'?', maybe implement using a suitable forest of symlinks.
(E.g. ->
do/alg-ab/zone_with_md_ab.txt, or ->
no-do/alg-a/zone_unsigned.txt, or .../do/alg-a/zone_with_md.txt ->

Basically, provide info to both the consumer and producer, about the state
of things.