Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-01.txt

From: [email-masked]
Date: Tue, 09 Nov 2021 14:59:56 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : DNS Error Reporting
        Authors         : Roy Arends
                          Matt Larson
	Filename        : draft-ietf-dnsop-dns-error-reporting-01.txt
	Pages           : 10
	Date            : 2021-11-09

Abstract:
   DNS Error Reporting is a lightweight error reporting mechanism that
   provides the operator of an authoritative server with reports on DNS
   resource records that fail to resolve or validate, that a Domain
   Owner or DNS Hosting organization can use to improve domain hosting.
   The reports are based on Extended DNS Errors [RFC8914].

   When a domain name fails to resolve or validate due to a
   misconfiguration or an attack, the operator of the authoritative
   server may be unaware of this.  To mitigate this lack of feedback,
   this document describes a method for a validating recursive resolver
   to automatically signal an error to an agent specified by the
   authoritative server.  DNS Error Reporting uses the DNS to report
   errors.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Nov 2021 19:52:26 +0100

Hello dnsop folks,

Discussion with Manu Bretelle in the other thread got me thinking about 
the subset of codes operators want to hear about. Let's think a bit 
about this part of spec:

On 09. 11. 21 23:59, [email-masked] wrote:
> 6.1.1.  Constructing the Reporting Query
> 
>    The QNAME for the reporting query is constructed by concatenating the
>    following elements, appending each successive element in the list to
>    the right-hand side of the QNAME:
> 
>    o  A label containing the string "_er".
> 
>    o  The Extended DNS error, presented as a decimal value, in a single
>       DNS label.
> 
>    o  The QTYPE that was used in the query that resulted in the extended
>       DNS error, presented as a decimal value, in a single DNS label.
> 
>    o  The QNAME that was used in the query that resulted in the extended
>       DNS error.  The QNAME may consist of multiple labels and is
>       concatenated as is, i.e. in DNS wire format.
> 
>    o  A label containing the string "_er".
> 
>    o  The reporting agent domain.  The reporting agent domain consists
>       of multiple labels and is concatenated exactly as received in the
>       EDNS option sent by the authoritative server.

> 4.2.  Example
>    _er.7.1.broken.test._er.a01.reporting-agent.example

Using RFC 8020 ("there's nothing below NXDOMAIN") or RFC 8198 (DNSSEC 
aggressive cache) an operator can effectively cut out some parts of the 
"reporting subtree" and dampen queries for it. This enables various 
tricks, depending on how we construct the query name:

_er.<ede code>.<qname>._er.<reporting agent domain>
_er.<qname>.<ede code>._er.<reporting agent domain>

A) Variant A (current draft):
- I'm operating domain "petrs.example"
- subtree "dnssec-failed.petrs.example" is a playground which 
intentionally fails DNSSEC validation (sorry Manu :-))
- error reporting agent domain is "agent.test"

I use domain dnssec-failed.petrs.example in a piece of Javascript which 
renders "DNSSEC validation does (not) work" text on my web front page 
page, so it gets queried fairly often, and I do not want to hear about 
failures in this subtree.

Within the current draft it can be done with agent.test zone file like this:
$ORIGIN _er.agent.test.
* TXT "tell me!"
dnssec-failed.petrs.example TXT "silence"

Wildcard expansion rules & RFC 8020 & query name minimization will cut 
out the whole subtree, saving traffic and also noise in data received by 
the reporting agent.

B) Variant B:
- My domain "petrs.example" hosts a really nasty political satire, and 
it gets censored a lot
- I don't care about reports of EDE "Censored" because there is nothing 
I can do about them anyway
- I still _do_ care about technical issues.

To make use of the same technique as in the previous example (wildcard), 
we would have to switch order of elements in the reporting query to:

_er.<qname>.<ede code>._er.<reporting agent domain>

This structure allows to use the same trick on per-EDE code basis:

$ORIGIN _er.agent.test.
* TXT "tell me!"
16 TXT "silence"  ; 16 = EDE Censored

The question is: Which variant is better?

I don't remember from our previous discussions if the current ordering 
in draft was a conscious choice or not, sorry if I forgot.

Have a great weekend everyone!

-- 
Petr Špaček

---

From: Manu Bretelle <[email-masked]>
Date: Fri, 12 Nov 2021 15:25:52 -0800

> 16 TXT "silence"  ; 16 = EDE Censored
I was actually wondering how this family of code (specifically 15, 16, and
17) would be handled given that they are "local" policies more than actual
errors in regard to the authoritative name server.
But as an extension, how a resolver would keep tab on what should or should
not be reported.
This is likely an effective way for auth operators to silence what they do
not care about

> in draft was a conscious choice or not, sorry if I forgot.

On a first read I thought this was trading effectively stubbing out EDE
code but losing QNAME level solution, but assuming that non-terminal
wildcard are widely supported (RFC4592 section 2.1.3. [0]), it seems that
we could benefit from both world by silencing domain specific with:

```
$ORIGIN _er.agent.test.
* TXT "tell me!"
dnssec-failed.petrs.example.* TXT "silence this specific domain"
16 TXT "silence this specific code"  ; 16 = EDE Censored
```

There is still the QTYPE to fit somewhere, but it seems the same logic
could apply?

Enjoy the weekend!

Manu

[0] https://datatracker.ietf.org/doc/html/rfc4592#section-2.1.3