Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

Shumon Huque <> Thu, 07 May 2020 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB9A93A02BC; Thu, 7 May 2020 05:34:36 -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 t5ZnYeEIbf-k; Thu, 7 May 2020 05:34:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADDEC3A02BB; Thu, 7 May 2020 05:34:34 -0700 (PDT)
Received: by with SMTP id p16so5187536edm.10; Thu, 07 May 2020 05:34:34 -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=QFvWaiYT9J0vN8yek7Up350SBQZycFqNc5m5ZhkStJ8=; b=YszZK1V5liGXLFiycIzEcAyksqvHzYGm5SI2K4FqIDFir9bIbQ36fGGbMV94uMJu6E sk1lxyXjcICKfaQ4MQ4Z/oQj5F3aorjNFYGkLtdybHCBEa78ssCc7YkS3BRJiSghZypW a634M/OA3Yt56yTwc2v6mM00AmfHnYUYlq1U6jjGzCtTksVs7PVb2f3Z4IU/ydCHRNWx afgPp5b0+wcH/8jbvM+w88ZiYCnv13NNo3B2SOsxrHz7ibE1pFiHSi47V6+O3VUA2ZRv yU3ta5lbQ7QFzgMTVlrw8jKEt/O69KXhjggjA+Bvi8jpXhgrWspB+AM7xfj2xY6gZbK5 PmBQ==
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=QFvWaiYT9J0vN8yek7Up350SBQZycFqNc5m5ZhkStJ8=; b=OpdCsyWRVe5Di1wRwo61X8Zte2cbM9qbvcqjuBwFd5Lt9epHGsuo0ObLP1eT1/PAXq GqgYDLtOzH5vAqzPk1qRk6tkkBEIWeq45153ksbOUxR8vyGad5qcejHciX6pmzIe1aUg Cb7GogKkLRhb+VxIh/27uHHvjuqyJpFIFfF4c/A1k6cmUh5wOJZ5lt8YmGhvyRTDufQ4 boUk37S+sI3GADInnxdayOqH8E0rj9+Yz8J9qJ6T/VRyJROnXQPbIZhbFJWIUp7R1UFU sTym6l5a6nd2MFTmlMq+NIH3xGIolrOjw8APC9jgGpxG1BZ+f/b5CEy/KES4rxqLAV1J r8nA==
X-Gm-Message-State: AGi0PuaZ/HR1vcWylcR3CyzPcYItrWizRiek/eZS7zOEyf7vXWclhmgI pWvt4hZbkJjmQuxiSYszTmGaBZx0J2MVi0szhSo=
X-Google-Smtp-Source: APiQypK1s8mBT/T5F8lxf4J2x3PAvXRglc1l1Mn+PDlqW3jTeCdsWEiXJNoNF1Pqfi9/v+/pvJqp8KQv4lIe969ivRs=
X-Received: by 2002:aa7:d783:: with SMTP id s3mr11975267edq.64.1588854873203; Thu, 07 May 2020 05:34:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Thu, 07 May 2020 08:34:21 -0400
Message-ID: <>
To: Stephane Bortzmeyer <>
Cc: Tim Wicinski <>, dnsop <>, dnsop-chairs <>
Content-Type: multipart/alternative; boundary="00000000000051258705a50e1a72"
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
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, 07 May 2020 12:34:37 -0000

On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer <>

> On Mon, May 04, 2020 at 03:08:20PM -0400,
>  Tim Wicinski <> wrote
>  a message of 64 lines which said:
> > This starts a Call for Adoption for
> > draft-mglt-dnsop-dnssec-validator-requirements
> I think it is important to have such a document, because DNSSEC
> failures may seriously endanger the deployment of DNSSEC (which is
> already too low). The current draft seems a good starting point and I
> support its adoption.

I also support adoption and will review/contribute etc.

I'm willing to review. Let's start immediately with -09:
> draft-ietf-dnsop-extended-error (recently approved by the IESG) should
> be mentioned, since one of the biggest operational problem with DNSSEC
> is the difficulty to understand why a resolver returns a SERVFAIL to
> you.


> More often, to date, failed validation is due to operator error and
> > not an attempt to forge data.
> It can be a bug in software, too. Specially with complicated things
> like NSEC3+optout+ENT+dynupdate :-{

Yes, unfortunately I concur. My experience recently deploying DNSSEC
for a large organization made it clear to me that even recent versions of
mature DNS implementations often have a variety of operationally
impacting DNSSEC bugs.

The draft apparently do not mention advices on expiration slack (such
> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
> consensus on (I quote Unbound documentation) "The signature inception
> and expiration dates are allowed to be off by 10% of the signature
> lifetime"?

RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having
a reasonable signature inception offset, but recommends no value. It does
not mention a signature expiration skew. It would be good to treat this
subject in the document. Personally, I would prefer a fixed value (~ 5 to
10 minutes) rather than a percentage. Otherwise, the validator may be using
a possibly unacceptably small or large skew values depending on the validity

> However, a DNSSEC validator is not able to determine other than by
> > trying whether a signature scheme is supported by the authoritative
> > server.
> This one is unclear. First, the signer is not always an authoritative
> server, signature can be done offline. Second, querying the DNSKEY is
> enough, no? (Or querying the signatures, but I assume a zone won't
> publish a DNSKEY without being able to sign with this algorithm.)

As the spec is currently written, yes, the DNSKEY RRset will give this