Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Paul Wouters <paul@nohats.ca> Sun, 21 February 2021 22:09 UTC

Return-Path: <paul@nohats.ca>
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 303F63A134E for <dnsop@ietfa.amsl.com>; Sun, 21 Feb 2021 14:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 8Lg1SzdOqJ9R for <dnsop@ietfa.amsl.com>; Sun, 21 Feb 2021 14:09:44 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41783A1371 for <dnsop@ietf.org>; Sun, 21 Feb 2021 14:09:14 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DkKGc1FMVz388; Sun, 21 Feb 2021 23:09:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1613945352; bh=bHLq/Php1GeYKaOfpCzWFIbKg01Zt1VNJKq3TToFPw8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=m+jHcf2onooFXDZeJbSE4TAo6U4VGW/sC/QX05TjUa3bZG8mzTRkuwf7L6yGtOOxQ H2thzhR/laOUC67YQ9WB/hL753q+n947Govvwvky9pmd1QR7URhIZtO2cbSwIz/48/ 1WyGMnnHI4b/qdMdrgjq17zJj6SeZIeurskrQVDY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Xf5um5Fc3l8j; Sun, 21 Feb 2021 23:09:11 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 21 Feb 2021 23:09:11 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B61536029B62; Sun, 21 Feb 2021 17:09:09 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD70B66B1E; Sun, 21 Feb 2021 17:09:09 -0500 (EST)
Date: Sun, 21 Feb 2021 17:09:09 -0500
From: Paul Wouters <paul@nohats.ca>
To: Petr Špaček <petr.spacek@nic.cz>
cc: dnsop@ietf.org
In-Reply-To: <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz>
Message-ID: <47eb552c-28df-aeee-aa35-6116f819cd6b@nohats.ca>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dspmxQvlvf1n8VEbT2NTWlkwGLI>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
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: Sun, 21 Feb 2021 22:09:53 -0000

On Thu, 30 Jul 2020, Petr Špaček wrote:

> I'm going to generalize Ben's questions:
>
> It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having description of "DNSSEC Trasparency" mechanism available.
>
> Please describe intended usage of the proposed mechanism, at the moment it is hard to see all the details and interactions.

I think the draft clearly explains that without delegation-only, a
parent can just present any record of the child zone from within
its parent zone, as if there was no delegation. Even if there is
one. That is, it can still serve DS records, but also service
TLSA records past its zone cut. So if a resolver asks the .ca
nameservers for _443._tcp.nohats.ca IN TLSA, the .ca nameservers
could serve it while still also serving DS records for nohats.ca.

With this flag set, it can no longer do this and it must switch its
mechanism for overriding the child by modifing the DS for this child.

I think a concept of DNSSEC transparency where a DNS validator plugin
logs all different DS RRsets (and NSECs) from delegation-only zones and
uploads these once a day to a dnssec transparency monitor is a fairly
basic concept that I think this draft does not need to further expand.

Paul