Re: [DNSOP] DNS Error Reporting

Brian Dickson <> Fri, 12 March 2021 03:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6AC13A0E10 for <>; Thu, 11 Mar 2021 19:47:22 -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 Ui0Q-sJlpjHw for <>; Thu, 11 Mar 2021 19:47:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D40153A0E0B for <>; Thu, 11 Mar 2021 19:47:20 -0800 (PST)
Received: by with SMTP id x8so1316909ual.6 for <>; Thu, 11 Mar 2021 19:47:20 -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=yI52+evz5LFOlrrnhf6aFUjaa/7fqHzTbEWK19x7cYc=; b=Pt/F0DVToGcboOe4zJ7xo2Q55+tNMZEIjtCghjaIPsdyEUyH2GjoUDEI1SZ90ZD2GQ Z0HQIjM4C1yptshhmmCyXktr5yGZbFr27Y3cZJXzqN1n1OcWJMP9KLkkiLGlus7hcpeZ P0BkjeKrChpJeEWWtDwc5x4+lE6G2U0uiGcjS+IUM3hLC4Pw3aoQ+FhYthUTztPRCv8n vJSp9criBQew7b4S0BLKyLjku7LrDfzNy3DupEH2W1iAPXQWJowwfc0z2d8h48g7dTD2 /qcQVZuhuCnAL6FZss5C94aElxW7/Ohsg1hfZb6K+AhzaMtLJC4P7dHuv73Dz8ddfqNx aDtA==
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=yI52+evz5LFOlrrnhf6aFUjaa/7fqHzTbEWK19x7cYc=; b=r5b5D0EgF0lERZLFElSDK1qjy57ghW0gqBzYxil9glXW+VvJWxLiFOj10d7GhDvzyd kG1HEksI/0S4TQ+hoo4avPq7t/GD2Z+e13EGgPqCG8DnG2hHH3CiUxOEYkX/0Vjs2o0v odLhsq+ECURS0gKfuQLUjD2z8S14Gi4LbvVJumLoE02AMAgNAMrP22UtfAAmkP0aHTfr Vi8NCFyDGcGDgWJckydpIztloLk8xJmUTZgQP+t/x6fU1eaI6FQqRo1adLjZ8I+NJ6dj wrJYNj84tO5idVLy6v1FmiAGpqFCkDAhxAKBc2wRJDWsfJi5s5ieNgXaZhdP94uk1msE 5LQA==
X-Gm-Message-State: AOAM531jtz6sZxShr8xcr81Fb/1IluXxI7mgZxMoyUo6ZcrTFnJcFVgX UxcnVmAAR8kjcW/kPAzPw1Le+quNpvtGs9Tx5bmLLRU+
X-Google-Smtp-Source: ABdhPJx7fbVI4clRNLhTXmfcMClc5sjxGQbimdAB7V8c0k2HqVJEViCxDKe2QOj3uHEp/Ha7thD216pPpeRzslFV47M=
X-Received: by 2002:ab0:2651:: with SMTP id q17mr7217261uao.87.1615520838985; Thu, 11 Mar 2021 19:47:18 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 11 Mar 2021 19:47:08 -0800
Message-ID: <>
To: Roy Arends <>
Cc: dnsop <>, Matt Larson <>
Content-Type: multipart/alternative; boundary="000000000000bc39f805bd4ec122"
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: Fri, 12 Mar 2021 03:47:23 -0000

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

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.

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.

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?

BTW, I like this and hope it sees widespread adoption in the operator