Re: [DNSOP] signalling mandatory DNSSEC in the parent zone

Brian Dickson <> Mon, 01 March 2021 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B595A3A1FFC for <>; Mon, 1 Mar 2021 09:28:06 -0800 (PST)
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 eGE0trefxN9j for <>; Mon, 1 Mar 2021 09:28:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44A903A1FFE for <>; Mon, 1 Mar 2021 09:28:05 -0800 (PST)
Received: by with SMTP id y35so5839479uad.5 for <>; Mon, 01 Mar 2021 09:28:05 -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=1PsTnjLd3yH0teggK59u3FDJZIYWR1cfvOoP0Be2Ov4=; b=TBY69b8Ju/NOnSsmLYpvTAImoeBhzI48o5bKssvrmeWD5qElIVmSm8Lx0tO3bV7Anz aq3i45RN3PQ0uW+RaH45A4xM+FUTnyT48sAbJmpmBYXBi4xqnHW+fNRrGIenU8WE1xcC 8dNYh3CM1vx8ra0+CzPgR+kKgQhGRoPuRzpU2Sezp7Q5CzPRoFEL+/hFLfsbXrFbDfOL 2tl10RWS7wcpl9FiPIiE+/JBMb6YYmbctJ3h6FlS703YXa9Uz30cwgn7buCb47ib4STd PYHHqtXLzPOwLHUug9OCbaBNSKebS7Y/eYyJeg87KnbtiUm7ckrjjJtQSDcwbElnncKK wOZA==
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=1PsTnjLd3yH0teggK59u3FDJZIYWR1cfvOoP0Be2Ov4=; b=GwaRklGErK798kNmu8+silQXs/rwhez5Q/nbSD9hzR7TudRQf6n/BG8UcyM8A613Fr reQHFK98B3eL8jrCvUiT3WCd10NqaF1DlE2cDV9YBOUZD2RnaOJe03gunIewqM0WaOo/ UuHMzOIEbXbuFTp/g4I7tRTMo/MN7lIruItwPSolHdXCKDRf69aUrtMPy9IsXzpBStaU HkyUDUIc6yPTXjSjzy2rDWu5T4xWPdUmqc9r12ouiSwIHPqjn3qRdDTlWdn1iLCU4fHW ADzIqA+Ul2TaScEGz+LdnIvp8/L99X/15+diL0Cphpbl9weaz+D8hv8SaqRX0++L58yb kz4g==
X-Gm-Message-State: AOAM531e0Omyl/WrQNE1/EiPuzoU3qja+AmOGmP0BN9EuRVILShy/pTW L5GzlnDiGf2j40U7k3ACOm1k/HObkd6xL+fPZ8SwQKua
X-Google-Smtp-Source: ABdhPJw9iNujCj9g0PFMhDFP2vXqrdNZMz6Wy0JiWlk0fLAmpZ4Ilg3913NzXM+DlZrJdxvBp/+4zYls1+Hshlubyhw=
X-Received: by 2002:ab0:758b:: with SMTP id q11mr9201985uap.114.1614619681886; Mon, 01 Mar 2021 09:28:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Mon, 1 Mar 2021 09:27:50 -0800
Message-ID: <>
To: Ulrich Wisser <>
Cc: Jim Reid <>, dnsop <>
Content-Type: multipart/alternative; boundary="0000000000009615ca05bc7cf0d9"
Archived-At: <>
Subject: Re: [DNSOP] signalling mandatory DNSSEC in the parent zone
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: Mon, 01 Mar 2021 17:28:07 -0000

On Mon, Mar 1, 2021 at 7:46 AM Ulrich Wisser <ulrich=> wrote:

> Hi Jim,
> I don’t want to signal this to resolvers, there is no need to. As domains
> are resolved by themselves a resolvers doesn’t need to know if all other
> subdomains of .se are signed too, just that the one it is interested in is
> signed.
> But if .se would have that policy, how would you move a domain between
> name server operators?
> - If approved by the chairs Shumon and I will present our work on
> automating this at the next dnsop meeting.
> - if the operators do not support the same algorithm, only lax validation
> can save you. (And that is how this discussion started)
This should be highlighted to keep the conversation moving in the right

   - Switching providers while staying secure requires inter-provider
   cooperation, including publishing ZSKs from both providers in the DNSKEY
   RRSET served by both providers.
   - Doing lax validation MAY be necessary (if the algorithms used for
   signing the zone do not overlap)
   - Doing lax validation is NOT SUFFICIENT, i.e. only adding lax
   validation is not enough to not break validation - the inter-provider stuff
   is necessary too