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

Daniel Migault <> Wed, 06 May 2020 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 466E33A093F; Wed, 6 May 2020 14:48:44 -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 McewA5NQjDAz; Wed, 6 May 2020 14:48:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 167753A091A; Wed, 6 May 2020 14:48:42 -0700 (PDT)
Received: by with SMTP id s11so2048782vsm.3; Wed, 06 May 2020 14:48:42 -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=6sheKa8O7jgImMGJJxQEAknIASQZYZpRQ39cJZLwyUI=; b=N+nhmVG7ZEo6D/xpkNV426LGh4qo6O667l1HTk307nG9pKgvOonLML0n4Jjq6u725y OD37WM8QYzbE5GeWXMQrNb5r9MMXmP9j9rxw/WEvl/gvxY40SQ1HJhSFq9qtkjp8T89m b5bHkC4MHEW3HT3KQt+/6oEXGqiKEDs4n/qvNgULnDSIMgbuDVaHZ6rrCFzqpP/Gw+pW jMom7+x2Wm6gOym8O/jb0k4g0gaW/vGQ/d55ei5HzVRZnfpUEjfWr9pOMx9jZJIxD89s B164UI77gA8Koo8Y2Cg8ameaBdDUN81FhJEOtq5t8cUogA7Ij06IuYi0XCzlNzdlg7sV 4j1g==
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=6sheKa8O7jgImMGJJxQEAknIASQZYZpRQ39cJZLwyUI=; b=NkPqtAlWsdaBkP4MoT9AyyWtRVSEvfGbbtlzgJL1caz7TDmHV62drmV8J+HK5uEI8U mZqbFc22YhxnJrg5h+Aku9gzPPF3tsG2+No+jJJudlkliJrGize6xkwTeEm2Ke5Nvn7U E86B8U58HTCzjU9Gwa4A+ZMNx9p+5pG8IDxbLgp1RFeaP5q4BcqmS+2bps73ykoKkww+ MHm0VblsJ8sw9NyiPilnTrguNc8+WeWM5QF7uOvX+WxlPImffMh/tPBRRaCC9I4ctwIb hQzdLuEPYo2AWtVNOME5HMuRhfT/WpjSLJHgt0WZA1nlFvzbG5KwDBVQWB4e/VVsqk62 VweA==
X-Gm-Message-State: AGi0PubTJ0byrV25gSBPcQdeM3x5FdNQk7Df11XGpDEGI1WRUtxS/Owy uXh9Yf8DbX3y8lwdDVCVFJheZzg7qn31dMgFU8A=
X-Google-Smtp-Source: APiQypIk9mKUhuS9DTklKuwTrXT/ZfZqSAQdeF0NTfXMI35k5lhcTN/9U+Eu49QhiYVflGPxB5V/odv2uHSU7KLxlbY=
X-Received: by 2002:a67:2e01:: with SMTP id u1mr9120023vsu.31.1588801720720; Wed, 06 May 2020 14:48:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Wed, 06 May 2020 17:48:29 -0400
Message-ID: <>
To: Stephane Bortzmeyer <>
Cc: Tim Wicinski <>, dnsop <>, dnsop-chairs <>
Content-Type: multipart/alternative; boundary="0000000000002ea25405a501baa5"
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: Wed, 06 May 2020 21:48:44 -0000

Hi Stephane,

Thanks you for the comments. Please see inline my responses.


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'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.
>  This is a good catch and the DNS client side is yet missing in the draft.
Activation of EDE should be recommended. This provides the DNS client  has
a better understanding of the resolution, increases trust in the resolver.

I have created an issue here and will come with additional text.

> 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 :-{

This is correct. I cannot say this case the "bug" is entirely clear to me,
but at a high level the problem was due to a difference of interpretation
between a signer and authoritative server. This resulted in data the
resolver could not result in a proper validation. Even when fixed on
the authoritative part, some resolver were not handling this properly. I
believe that the experience associated to that bug could impact the
document as follows:
1) the draft should mention that validation failure can also be due to
software bugs.
2) we should have a recommendation for running different implementations
and provide the ability to switch to one in case a bug is detected.
3) What is unclear to me is how EDE could have helped in this case.

I opened the following issue:

> 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"?
Correct. This is not considered in the current document. I am happy to
consider the consensus. The following issue has been opened:

> > 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.)
Correct. In this section I wanted to emphasize on providing a validator
some means to ensure that it can safely deprecate an algorithm. While a
resolver that supports a signature scheme can apply that signature to all
received signed RRset. On the authoritative side, each zone needs to be
requested. The problem associated to request this is mostly the knowledge
of the zone.

I think the section should:
1) clarify the text and mentioning how the signature schemes are discovered.
2) It is unclear if we should keep track of the requested domain, in order
to be able to request the DNSKEYs
3) emphasize on a communication of supported algorithms between
authoritative servers and resolvers.

I have opened the following issue:

Section 12 "Invalid Reporting Recommendations" is questionable. Since
> most DNSSEC validation errors are not attacks, reporting these errors
> may overload the DRO with problems she can do nothing
> about. Monitoring is a good idea but monitoring what? "Important" (for
> the DRO) domains?
I agree that we could be a little be more specific. At minimum I envisioned
logging the domains with the number of failures and reporting those with a
I opened the following issue:

> Also, the draft has many, it seems, grammar / language
> problems. ("This introduces a potentially huge vector for
> configuration errors, but due to human intervention as well as
> potential misunderstanding of ongoing operations.")
> This erro has been raised by Bob and already corrected in the version on
the repository:

The correct text is:
This introduces a potentially huge vector for configuration errors, due to
human intervention as well as potential misunderstanding of ongoing

Others grammar and language issues have also been corrected.

> _______________________________________________
> DNSOP mailing list

Daniel Migault