Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]

Brian Dickson <> Fri, 25 September 2020 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E700A3A1407 for <>; Fri, 25 Sep 2020 11:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 G4IlIkskDBCQ for <>; Fri, 25 Sep 2020 11:06:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A1E73A140B for <>; Fri, 25 Sep 2020 11:06:02 -0700 (PDT)
Received: by with SMTP id j3so1925908vsm.0 for <>; Fri, 25 Sep 2020 11:06:02 -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=LI2FeF6MXUERSjzdMs3cR0/aJw4Txig17xheKmcYXLo=; b=tEYz3uuqiDLaU59VyxwX7ve18CAQvyH+cpe9lQIfZDctW/63j0Xq4Q0melOW/Y4P22 3a/OckTpYbH1Gh1kRJEN6XI0LYJvOnWNljjLAblccSWZAAR+TrMsVyXDKg4z4+taWib3 A0UXHtbNWPB5yW5MWC3XXQHyYVmJbGLedPw5U3qQjjNevKzaUJwRPTdxm8PHqomSx/oK Ee5arIFUUN2xwArSt75dWweTBhAjNbn8A8RJ/sQbu3fJw3FX6NPuS6NNEaLwtot4IgET NXRGIdPEihLigqrGU2QCC5JEzQezxdMh3Gy504CfvI6vLEQKRepaLvxKUe0t3vndyRUz lCbg==
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=LI2FeF6MXUERSjzdMs3cR0/aJw4Txig17xheKmcYXLo=; b=g5kqlX+mXIyafwtjmlHznl+PNaWJT52hC0I2/4qrWV0qtTb1/evOFA+9UwVUaJmkyi Kz7Kx3r98NsVeRT8X+uQLzQF2FpQ09mTO5by7qu366ZQHuXe4PeFWeB4/4RKqdxAGM0i l7DsZmluPnDftuw9QOKgWUdfq39P7AEJ+eciCdrFVOoX2MBDZ6C9dpYN5Qc1fN2bN02j USmYQdTMWWTaSdaUAgWc/DRd0LSGi8ZGBQV0NdVy3fH0CD56zLqSDe7ds6FC6j0MnwxQ iipERTON2tKywQdeqkZ/kkpCJ4PnC1jKR6mGKNCRSJNHpH5/E1KsUTnkuK52km8tqJds wGZQ==
X-Gm-Message-State: AOAM530b1KcgMoY1uipOlEbwDEfVzKyhTfBgZGAuZMJ6d0vSvgqckCDt v6JYhZnjYdMBhIQaaYWbKFtaxrO1oJJM3fTpCC8=
X-Google-Smtp-Source: ABdhPJzEdS8Qu4ZI98T1hQTJUYfxIc8H8I/2k5Fk888HuBffQzuAhnMKgy1Oy8EUsvc2JuEaoO0QDmWCpGIT2McvLgg=
X-Received: by 2002:a67:1d86:: with SMTP id d128mr550602vsd.58.1601057161425; Fri, 25 Sep 2020 11:06:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 25 Sep 2020 11:05:50 -0700
Message-ID: <>
To: Peter van Dijk <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="0000000000005f367e05b0272bc9"
Archived-At: <>
Subject: Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.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: Fri, 25 Sep 2020 18:06:04 -0000

On Fri, Sep 25, 2020 at 5:36 AM Peter van Dijk <>

> Hello dnsop,
> in this new episode of 'enabling future innovations that we perhaps
> cannot even imagine today', please find below a link to a draft
> proposing a DS digest type that does no digesting at all. This allows a
> zone owner to publish information in the parent zone and have the
> parent sign that data on the owner's behalf.


Please read all of rfc5507, and in particular section 5, on why this goes
against IAB guidance,
years of operational and developer experience, and is a horrible, horrible

Do not overload (re-use) RRTYPEs, period.

Also, beyond the potential use case of having parent-side non-authoritative
data DNSSEC signed,
by using a different RRTYPE for the delegation side of a zone cut, and
having a way of discriminating
glue records (such as A and AAAA) from non-glue equivalents, so that the
parental size of a zone
cut can DNSSEC sign these records, the entire design of the Domain Name
System is built around
the delegation principal, which is that the only place data is
authoritative is below a zone cut.

Having the ability to push data up to the parent side, which is controlled
by the child side, violates
the implied security model of the relationships between zones, which
roughly correspond to the
relationship in the Unix file system of directories, symbolic links, and
mount points. The corresponding
mechanism would be to allow an unprivileged user to "give away" ownership
via the "chown" command,
to a privileged account. This capability was extensively abused in the Unix
world until it was blocked.

Implementing this mechanism in DNS would almost certainly be abused in
similar ways, with the same
end result, of having to disable that mechanism due to abuse. This is
reason enough not to even start
down this road.

I'm happy to provide example use cases, but don't want to distract from the
general model being bad,
by playing whack-a-mole on examples and retorts. (See Warren Kumari's email
signature line about
pants and weasels for why.)

With respect and no offense intended.