Re: [DNSOP] DNS Error Reporting

Petr Špaček <> Wed, 17 March 2021 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A76EF3A14DD for <>; Wed, 17 Mar 2021 14:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=Ybetb3nw; dkim=pass (1024-bit key) header.b=ba2C4QoF
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZpnN7n6QmoxI for <>; Wed, 17 Mar 2021 14:05:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 108C83A14DC for <>; Wed, 17 Mar 2021 14:05:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 247483AB01F; Wed, 17 Mar 2021 21:05:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1616015107; bh=al3ASXAT+rBgNMo+9s2Q3v4kXd2YQoQKP+fnY3X1zy8=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=Ybetb3nw4QqP0Iwj1rOwawTOaIU2qOqlzrSw7Nqkb8i13lFOFkzDlgriiFLPI3b3G XJuLIMrOM2ttWwrQpR4kK29hQIJEWSRjNQ4dH8UJst+0lYqNFIyQJDhULzj+yKASbJ BTLg/s3+6fd6iAZoPUGmGjV1ntomqAX18Kzrn2E8=
Received: from (localhost []) by (Postfix) with ESMTPS id 0A479160079; Wed, 17 Mar 2021 21:05:07 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D851E16003F; Wed, 17 Mar 2021 21:05:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 D851E16003F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1616015106; bh=kcAjpRhjShHcFEjf5PeSGB1UDpxHPr3orfnTTo55wDo=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=ba2C4QoFlIF69/oiAhACKm6Z25IeZGynqeCR82WbzAhcDV7hLI5p/15r81ERFRhxG LAEXq+mr57Sq7b1uCQ1YbzbfDD9TcJEnzYxMX6nNI+zAFj9C+9uQcLmpycTKLSVIAr 6AaePMVcV4xSFVRk6vD70sXcEcmBIyzvfVl0Hwcg=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id FmZ--jJq9fMo; Wed, 17 Mar 2021 21:05:06 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id CDC76160079; Wed, 17 Mar 2021 21:05:05 +0000 (UTC)
To: Brian Dickson <>, Roy Arends <>
Cc: dnsop <>, Matt Larson <>
References: <> <>
From: Petr Špaček <>
Message-ID: <>
Date: Wed, 17 Mar 2021 22:05:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] DNS Error Reporting
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, 17 Mar 2021 21:05:12 -0000

On 12. 03. 21 4:47, Brian Dickson wrote:
> On Fri, Oct 30, 2020 at 10:03 AM Roy Arends < 
> <>> wrote:
>     Dear DNS Operations folk,
>     Matt Larson and I wrote up a method that warns a domain owner of an
>     issue with their configuration. The idea is loosely based on DMARC
>     (RFC7489), and on Trust Anchor signalling (RFC8145).
>     The method involves an EDNS0 exchange, containing an “agent” domain,
>     send by the authoritative server  that the resolver can send reports
>     to in case of a failure.
>     Please see
>     <>
> I have a few comments (some were made in the jabber room at IETF-110), 
> mostly suggestions.
> First, what about a "sampling" field, treated as 1/N for a field value 
> of N. Do rand(N), and report only if you get a value of 0.
> A value of N=1 would always succeed (not sampled), and a value of N=0 is 
> "don't send a report".

No such field is needed, this can be done on auth side already. Auth 
side can already decide with single-answer granularity when to send the 
option, i.e. the sampling can be simply done by not/sending the option.
(Keep in mind the option is not cached.)

For example auth can send the option only on 1/100 of DNSKEY queries and 
nothing else (if desired). Or for 1/100 000 of all queries.

Doing so on auth side is much more flexible and does not complicate the 
prototol so I do not think complexity is justified.

> Second, what about a "fire drill" field, which is applied with a similar 
> 1/N logic, but triggers a report even if no error occurs.
> This would be useful for testing the reporting functionality without 
> requiring deliberate errors be introduced.

I feel the complexity (also in security analysis ...) is unwarranted. 
What use-case do you envision?

> Third, what about actually sending a response to the "report" query?
> If noerror, nodata, the reporting agent does nothing.
> However, if some particular response is received, use that in processing 
> future errors.
> The idea is to have some value returned, with a TTL used for how long to 
> ignore errors, or that specific error. (Maybe use logic similar to the 
> class and type fields from UPDATE?)
> That way, if the authoritative server has a problem that can't or won't 
> be fixed for some duration, it can suppress reports until that error is 
> fixed.

That's already part of the draft. The signaling query is normal (albeit 
asynchronous to the triggering query) so normal TTL rules for answers 
apply. The receiving side is expected to send back normal DNS answer and 
can freely use whatever SOA/TTL/whatever it desires.

> Finally, what about an optional field for resolver operator contact info 
> (e.g. vCard or similar), so the authority operator can follow up with a 
> human if appropriate?

Interesting idea, but it leads to packet bloat caused by data which are 
unnecesary vast majority of the time.

Are we (as dnsop WG) not concerned with packet bloat anymore?

Petr Špaček