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

Bob Harold <rharolde@umich.edu> Wed, 24 October 2018 18:31 UTC

Return-Path: <rharolde@umich.edu>
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 217AF129619 for <dnsop@ietfa.amsl.com>; Wed, 24 Oct 2018 11:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 rSM9la6DurTM for <dnsop@ietfa.amsl.com>; Wed, 24 Oct 2018 11:31:46 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D413012777C for <dnsop@ietf.org>; Wed, 24 Oct 2018 11:31:45 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id p11-v6so4752745lfc.6 for <dnsop@ietf.org>; Wed, 24 Oct 2018 11:31:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mNRoScfom5gb97+f3hoUzNoOEvdle/T6YvqQ89fjNGE=; b=OSwR38LUgjbGE+8kq6B6WT33JT7Ln8+7hYzCgpyJtmxXM+q4nmhycsV33EGuoDrpsq x7j4rLKAPb9MnZdDPupceN/j4/3R7ewBlt28o2Z1VzftCFoZQ67U+oXxHM5vOP94SSMP X9mMWTQWo68ODiVp7TBB11+hA3czAyUVXprHGwIoPSDRFkeI8osyBYOiGxAu72Zv2KRP mwThL3RDZ/UYU1VRFEI3Eu8nCa4fmVBxnnpene0H5SltEnuZBKlT8mxV2C09AvsXEjQ2 ftkyZch72kQOgj4llFQKqGufNNpzL+wSMRab3Du5a5AiQPPpW6StSaADYx5FxGwCv8qb ibFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mNRoScfom5gb97+f3hoUzNoOEvdle/T6YvqQ89fjNGE=; b=PnAL4aQSQAbM8WRYuuyM6DQjvVCXRUUSo2esAKL7wsUXBHDL5YB1ynqxHkhv4GudJT 1bP+tMb1bINzGBO8eazFkubFA0HdazgIucnzpGps+NqjVkMVO7C4MYtZxFLEipjlV41y q3baD1IBfiF55ypMVLj4EH5VCfUMUiHVO1W64yaEH7NGWsF1E5zdecYdWSqx13engo49 Y8V3PDR1e54ZnnUiGKIQDL/uF3ZBJWx6Ul5gDXHbW8AlbWRMdv73N+mwHx6AtpujBzHQ TbvVFtbz5557+cc+ZrVX8G6UlxL6X40t73RWoy4LOg42vM3zaHfUrOVkfbGTDIGyzliO Euow==
X-Gm-Message-State: ABuFfojFAKzVpWq4AeIgyLYq/C/bCuD1NiMAsp7YhOEgsnkW7vhLx+Jw ryAiFfxGX393XVNJSvN2PwTWpzV7s8O0pdRisYIwJg==
X-Google-Smtp-Source: ACcGV60dKM9zBaCISOrkbHcoy63GAGypY4kAOLjc8IATmSaSa7u9jsES9Zp9Sf2P0VwbiSU4fVPafxw+I6n+K9GK0Vw=
X-Received: by 2002:a19:df54:: with SMTP id q20-v6mr16408384lfj.130.1540405903919; Wed, 24 Oct 2018 11:31:43 -0700 (PDT)
MIME-Version: 1.0
References: <154020795105.15126.7681204022160033203@ietfa.amsl.com> <CA+nkc8CR3KL0EVfkWF2U1coRh+chhNxjGWNevOG++BAt0YDwXw@mail.gmail.com> <601062EA-8853-47D9-B535-F71F25C80033@verisign.com>
In-Reply-To: <601062EA-8853-47D9-B535-F71F25C80033@verisign.com>
From: Bob Harold <rharolde@umich.edu>
Date: Wed, 24 Oct 2018 14:31:32 -0400
Message-ID: <CA+nkc8CaZ3ZbdWRBts2Zk6zjwZ4upnYJvO3N7eczqem-XCzXVQ@mail.gmail.com>
To: "Wessels, Duane" <dwessels@verisign.com>
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b69f060578fdb21a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/68dE5hLTYsItLKNVqhXsfqSsXV4>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-04.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: Wed, 24 Oct 2018 18:31:48 -0000

On Wed, Oct 24, 2018 at 5:49 AM Wessels, Duane <dwessels@verisign.com>;
wrote:

>
> > On Oct 22, 2018, at 6:53 PM, Bob Harold <rharolde@umich.edu>; wrote:
> >
> > Just my opinions:
> >
> > Keep the Reserved field
> >
> > Include occluded data - it is part of the zone, even if never served.
> (Similar to glue data when a server has both a parent and child zone.)
> >
> > If you might have multiple zonemd records not at the apex later, why not
> allow them now?  Otherwise, your choice whether to restrict them.  (Someone
> will find a use for them, like verifying glue records.  Everyone else can
> ignore them.)
> >
>
> Thanks for the feedback, Bob.
>
> My thought about non-apex ZONEMD records is that ZONEMD has some
> similarities to SOA.  They both say something about the zone has a whole,
> and I know some software at least rejects zones with a non-apex SOA
> record.  OTOH, I don't want to make things unnecessarily complex...
>
> DW


Having since read more discussions on whether to keep the Reserved field, I
would say that if the Reserved field is removed, then we should only allow
one ZONEMD record, and it should be at the apex.  If we keep the Reserved
field, then let's allow ZONEMD records in other places for future use.

-- 
Bob Harold