Re: [DNSOP] DNS Error Reporting

Brian Dickson <> Wed, 17 March 2021 23:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B3E03A1835 for <>; Wed, 17 Mar 2021 16:49:23 -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 vpAQ8Fiq3vTu for <>; Wed, 17 Mar 2021 16:49:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6E9C3A1833 for <>; Wed, 17 Mar 2021 16:49:20 -0700 (PDT)
Received: by with SMTP id z68so566103vsb.10 for <>; Wed, 17 Mar 2021 16:49:20 -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=BpVPIO4tSEIbqIbUYIUr93cfHnV965Kr/p4gz1A1Va0=; b=Hrpn0rObhZBkCRVA6+8uX/6deMk3Qt0PCbCL28JE6NRgFrWA8sUG6W6xvWyJ3rsRUk FTlP0GMbL/Izdj9eVW0kLcsnwqnFegJb+xvDy/UzNdoVjKMD0PDgxYvQ93AVW8vx41D0 741mnGmSlHTq36Li0ReKh3gK8v+Fn+JPuDxqfYPb5aPLibNOwFDQgnB//miPhJdV6AS3 OD+2Nbr7ognyqi43RXLMN9NEtHV11f2emqf4Nh+dQq9ZIdk650+Jq0nGELFS5epksiBA uCdNK8EfSbU0oPsNpbXN+qxhi8bfwXl+3VRseNVO86h1tct4o3C/Q12xiyIt+5IHTist 2usQ==
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=BpVPIO4tSEIbqIbUYIUr93cfHnV965Kr/p4gz1A1Va0=; b=k5oCDmKf+h+E74fdx4ZSfeQVisHRHM6H0BexWuYY0xtbsYw64hld0V+NsgZ58ez5IK xM5GV1/w2dGg6iOtEaM4yQU3b7K2OUlKoNx6NJSqr0U0EgGaiuyHSuNy+WEtYWMLMGTM a+591xe+y2yE0VIHywbHx9SUcitMckO9ZwWWMmtLzDz5MK7ejIV7AgMSx1Lio7HNtliy QV6goAcqlJKSSV6ZDiZ+hX0kSV+7Shs5iUzI+z6MP8Jn2xxQqJTlb4Uw+QOsF3mZ1tL8 x2mWD3qlUqOSW2VKw8t7A/RgxDIvIZmJBwEcLC6B9o8DDGy5bN0ho+Hb4wmMaAq1VT3h bIhw==
X-Gm-Message-State: AOAM530I3exXdMZtMfyMh8fJ8nmZU7LR6nWFxEd2jaj3NGSXChU+Ka2W TrI4rPwGgoTEXEQUBus1yv34lvocBrxmwxPWFQE=
X-Google-Smtp-Source: ABdhPJwGB4wyDohUMBVx8a6nd0rM/KeurKvgYRLtmwztWB5Tv4GgLrGrgGgXHjEpoDlEZP27cdh2UjTO8rEVi1RRlmE=
X-Received: by 2002:a05:6102:539:: with SMTP id m25mr5417532vsa.41.1616024959470; Wed, 17 Mar 2021 16:49:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 17 Mar 2021 16:49:08 -0700
Message-ID: <>
To: Petr Špaček <>
Cc: Roy Arends <>, dnsop <>, Matt Larson <>
Content-Type: multipart/alternative; boundary="000000000000a84fa705bdc42129"
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 23:49:23 -0000

On Wed, Mar 17, 2021 at 2:05 PM Petr Špaček <> wrote:

> 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.)

Yeah, I was thinking of this only because I missed the bits about TTL and
cached answers preventing re-reporting.
I think the TTL lets the auth manage the report load adequately, so
sampling isn't really needed.

> 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?

Suppose someone sets up reporting, and wants to confirm that (a) reports
get received, and (b) perform a longitudinal check on which clients send

The use case for (a) is, the auth server operator that wants reports,
should know the full infrastructure for receiving reports works before
depending on it, and similarly whenever making changes to the reporting
system, that the change does not break reporting.
The use case for (b) is, the auth server operator is interested in what is
common between clients who do or do not send reports. For example, if no
clients behind a particular ASN are sending reports, there could be a
network issue (e.g. ACL, firewall, load balancer, NAT, whatever) that
affects all clients behind that ASN.

Both of these use cases require the client (reporter) send a report
regardless of error conditions (but modulo sampling rates).

The two options for this are, (i) break something being requested, for all
clients, to generate reports (not a good option), or (ii) use the "fire
drill" to trigger reports even if there are no errors.

I'm not sure I have done a good job of explaining this. Basically, a fire
drill is performed to simulate a failure, so the alerting/reporting can be
tested. It's similar to the "lamp test" button (which allows you to detect
burned-out indicators on analog display systems like in airplanes or
nuclear reactors.)

I.e. if you are setting up this reporting, it only makes sense that you
know it works, and to validate that you need to know it works from
everywhere, not just a few randomly chosen places.

The 1/N thing is moot with the TTL cache too, so just having a flag is

> > 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.

Ah, thanks, I missed that, so, never mind. :-)

> > 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?

This would add data on the DNS query used for sending the report. DNS
queries are generally very limited in size, typically less than 100 octets
Adding something like "TYPE|LENGTH|" on small
query packets for reports is not likely to cause problems for anyone,

So, maybe no real concern if the length is limited to some sensible value?