DNS Error Reporting
draft-ietf-dnsop-dns-error-reporting-08

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dnsop-dns-error-reporting and RFC 9567, changed IESG state to RFC Published)

[Ballot discuss]
[29/12/2023: minor updates to my discuss]

Can the qtype of TXT be explicitly mentioned in the abstract? Currently, one only finds out midway Section 4.

In Section 6.1.1. Constructing the Report Query, only the QNAME construction is documented, not the
QTYPE (or CLASS but there is a reference that says only IN is supported). It would be clearer to just
quickly repeat here the qtype is set to TXT. Otherwise, perhaps 6.1.1 should be retitled "Constructing the Report QNAME".

While no guidance on (TXT?) RDATA sending is okayish, there should really be a Security Consideration
on what to do with any RDATA. Let's avoid another vector for log4j.


        The reporting resolver MUST NOT use DNS error reporting to report a failure in resolving the report query.

This might be tricky to implement. The resolver might not know why another thread is resolving some A/AAAA
record. For example if nohats.ca uses a reporting fqdn of foobar.fi, why shouldn't validation failures on
foobar.fi try to report that to foobar.fi, if they themselves use a reporting fqdn.

Similarly, recommending disabling DNSSEC for these queries can be tricky, if resolving the reporting fqdn
requires a number of related DNS queries for NS, DS, A/AAAA, CNAMEs). I think it is better to not recommend
this and let failures be failures. If the reporting fqdn fails to resolve, abort trying to report the failure.

Which of course brings up: Should there be a consideration for the reporting fqdn not being in-domain ?
eg ns1.nohats.ca serving nohats.ca should probably not use er.nohats.ca.

The er QNAME construction assumes there was only 1 QTYPE. There are drafts being floated that have more than one
QTYPE. How to construct the QNAME for those?

Closed request for Telechat review by DNSDIR with state 'Overtaken by Events': Reviewer has not responded to the review he specifically requested and hasn't replied to email reminders. He will need to sit on the dnsdir naughty step and think about what he has (hasn't) done.

(1) The RFC is a Standards Track document and is categorised as such to
ensure proper compliance with the standards.  This classification is
considered appropriate because it requires seamless interoperability
between implementations on the global Internet.

2)

Technical Summary:


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.


Working Group Summary:

The WG worked together to address any and all issues. While the document had already undergone thorough review by both the WG and implementers, as indicated below, the WGLC period was extended by two weeks to include additional input from the WG before advancing the document to the IESG. All feedback has been further discussed on the mailing list and, if relevant, incorporated into the document.


Document Quality:

Document is of good quality.

In an early phase, proof-of-concept implementations of the I-D were realised during IETF Hackathons and interop tests were carried out. There are several implementations that have been in use for some time now.


Personnel:

Document Shepherd: Benno Overeinder

Responsible Area Director: Warren Kumari


(3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) no nits

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) No New Registries

(19) N/A

(20) No Yang Necessary

[Ballot comment]
This is a cool idea.  Thanks for advancing it.

I support Paul's DISCUSS position.

In the shepherd writeup, when there are implementations, it's helpful to include names or links to them.

[Ballot comment]
Hi,

Thanks for this document.

DNS really isn't my area of expertise, and it may be that if I was very familiar with DNS and DNS deployment then the approach taken here for error reporting would seems like the obvious and pragmatic choice.  Specifically, I do appreciate that this is a lightweight solution, and the solution may well be good enough to achieve its goals of better error reporting without too much effort and without causing too much confusion.

But, without the domain knowledge, I'm not particularly enamored on the approach of overloading the error reporting onto the basic DNS query mechanism rather than a separate message type or channel.  It feels a bit like if the only thing that you have is a hammer, then everything looks like a nail ... and ultimately I'm concerned that the error reports that looks like a query, but are not really a query, may end up being confusing in logs, debugging, etc., for non-expert users.  Hopefully, this doesn't happen when it gets deployed, and if it does then I guess that the plan B option of deprecating this approach and specifying a more heavyweight out of band mechanism always exists.

[Ballot comment]
Thanks for working on this specification. Thanks to Gorry for the TSVART review.


I have only two questions

- is this protocol (error reporting) not applicable to DoQ? The question came as TCP is the preferred transport and only tells what to do when UDP is used for queries and reports, so wondering what happens when QUIC is as transport for DNS.

- what would be a typical rate of error reporting?

[Ballot comment]
Thanks for working on this specification. Thanks to Gorry for the TSVART review.


I have only two questions

- is this protocol (error reporting) not applicable to DoQ? The question came as TCP is the preferred transport and only tells what to do when UDP is used for queries and reports, so wondering what happens when QUIC is as transport for DNS.
- what would be a typical rate of error reporting?

[Ballot discuss]

        This document gives no guidance on the content of the TXT resource record RDATA for this record.

Based on this, I assume the error report query is of qtype TXT, but this is not specified anywhere in the document.
Someone could use a qtype of CNAME or ANY or just A or AAAA. Can this be stated explicitly ?

In Section 6.1.1. Constructing the Report Query, only the QNAME construction is documented, not the
QTYPE (or CLASS but there is a reference that says only IN is supported)

While no guidance on (TXT?) RDATA sending is fine, there should really be a Security Consideration
on what to do with any RDATA. Let's avoid another vector for log4j.


        The reporting resolver MUST NOT use DNS error reporting to report a failure in resolving the report query.

This might be tricky to implement. The resolver might not know why another thread is resolving some A/AAAA
record. For example if nohats.ca uses a reporting fqdn of foobar.fi, why shouldn't validation failures on
foobar.fi try to report that to foobar.fi, if they themselves use a reporting fqdn.

Similarly, recommending disabling DNSSEC for these queries can be tricky, if resolving the reporting fqdn
requires a number of related DNS queries for NS, DS, A/AAAA, CNAMEs). I think it is better to not recommend
this and let failures be failures. If the reporting fqdn fails to resolve, abort trying to report the failure.

Which of course brings up: Should there be a consideration for the reporting fqdn not being in-domain ?
eg ns1.nohats.ca serving nohats.ca should probably not use er.nohats.ca.

The er QNAME construction assumes there was only 1 QTYPE. There are drafts being floated that have more than one
QTYPE. How to construct the QNAME for those?

[Ballot comment]
Thanks to Gorry Fairhurst for the TSVART review -- I would appreciate an email response to that review, though I think you've addressed more or all of the comments.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dns-error-reporting-07

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points.

Special thanks to Benno Overeinder for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

Other thanks to Carlos Pignataro, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-error-reporting-07-intdir-telechat-pignataro-2023-12-09/ (even if only nits were detected)

Other thanks to James Gannon, the DNS directorate reviewer, please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-error-reporting-07-dnsdir-telechat-gannon-2023-12-10/ (and I have read the discussions about James' previous review)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

I find it a little sad that this method is only applicable to DNSSEC (as there could possibly be other errors to be reported for plain DNS). Should this be mentioned in the abstract ?

In the same vein, should "resolve or" be removed from `that fail to resolve or validate` ?

## Section 6.1 & 6.3

Suggest to give some hints when the SHOULD in the last paragraph can be bypassed.

[Ballot comment]
Thanks for this useful and readable specification. I have one comment –

Section 6.1 says, “The EDNS0 Report-Channel option MUST NOT be included in queries.” Section 6.2 says, “There is no requirement that the EDNS0 Report-Channel option is present in queries.” While the two are not technically in conflict, the second understates; it seems like you could, and should, remove it. But perhaps there’s some subtlety I’m not understanding here.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-dns-error-reporting-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the DNS EDNS0 Option Codes (OPT) registry in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

a single new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Name: Report-Channel
Status: Standard
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the Underscored and Globally Scoped DNS Node Names registry also in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

a single new registration is to be made as follows:

RR Type: TXT
NODE NAME: _er
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-30):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dns-error-reporting@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Error Reporting) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Error Reporting'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/



No IPR declarations have been submitted directly on this I-D.

(1) RFC is Standards Track and it is the correct RFC type

2)

Technical Summary:


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.


Working Group Summary:

The WG worked together to address any and all issues. While the document had already undergone thorough review by both the WG and implementers, as indicated below, the WGLC period was extended by two weeks to include additional input from the WG before advancing the document to the IESG. All feedback has been further discussed on the mailing list and, if relevant, incorporated into the document.


Document Quality:

Document is of good quality.

In an early phase, proof-of-concept implementations of the I-D were realised during IETF Hackathons and interop tests were carried out. There are several implementations that have been in use for some time now.


Personnel:

Document Shepherd: Benno Overeinder

Responsible Area Director: Warren Kumari


(3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) no nits

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) No New Registries

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track and it is the correct RFC type

2)

Technical Summary:


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.


Working Group Summary:

The WG worked together to address any and all issues. While the document had already undergone thorough review by both the WG and implementers, as indicated below, the WGLC period was extended by two weeks to include additional input from the WG before advancing the document to the IESG. All feedback has been further discussed on the mailing list and, if relevant, incorporated into the document.


Document Quality:

Document is of good quality.

In an early phase, proof-of-concept implementations of the I-D were realised during IETF Hackathons and interop tests were carried out. There are several implementations that have been in use for some time now.


Personnel:

Document Shepherd: Benno Overeinder

Responsible Area Director: Warren Kumari


(3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) no nits

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18) No New Registries

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track and it is the correct RFC type

2)

Technical Summary:


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.


Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been in use for some time now.

Personnel:

Document Shepherd: Benno Overeinder

Responsible Area Director: Warren Kumari

(3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) no nits
Authors response to SECDIR review - https://mailarchive.ietf.org/arch/msg/dnsop/ncvsE9hQhRsV7usWUUPHHd-Ag4U/


(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18)  No New Registries

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track and it is the correct RFC type

2)

Technical Summary:


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.


Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been in use for some time now.

Personnel:

Document Shepherd: Benno Overeinder

Responsible Area Director: Warren Kumari

(3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) no nits

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18)  No New Registries

(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track and it is the correct RFC type

2)

Technical Summary:


  DNS error reporting is a lightweight reporting mechanism that
  provides the operator of an authoritative server with reports on DNS
  resource records that fail to resolve or validate.  A domain owner or
  DNS hosting organization can use these reports to improve domain
  hosting.  The reports are based on extended DNS errors as described
  in RFC 8914.

  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 a monitoring agent specified by
  the authoritative server.


Working Group Summary:

WG worked and collaborated on resolving any and all issues. No rough consensus.

Document Quality:

Document is of good quality. There are several implementations that have been in use for some time now.

Personnel:

Document Shepherd: Benno Overeinder

Responsible Area Director: Warren Kumari

(3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There have been no appeals.

(11) The following editorial nits were pointed out to the authors, who will update their document after hearing from the AD.

.
Section 4

s/unsollicited/unsolicited/

Section 6.2

s/Repprt/Report/
s/unsollicited/unsolicited/


(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) N/A

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section is accurate.

(18)  No New Registries

(19) N/A

(20) No Yang Necessary

Changed document external resources from:

github_repo https://github.com/NLnetLabs/unbound/tree/features/error-reporting-poc (DNS error reporting PoC in Unbound recursive name server)
gitlab_repo https://framagit.org/bortzmeyer/drink/-/commits/error-reporting/ (DNS error reporting PoC in Drink authoritative name server )

to:

github_repo https://github.com/NLnetLabs/unbound/tree/features/error-reporting-poc (DNS error reporting PoC in Unbound recursive name server)

Changed document external resources from:

github_repo https://github.com/NLnetLabs/unbound/tree/features/error-reporting-poc (DNS error reporting PoC in Unbound)

to:

github_repo https://github.com/NLnetLabs/unbound/tree/features/error-reporting-poc (DNS error reporting PoC in Unbound recursive name server)
gitlab_repo https://framagit.org/bortzmeyer/drink/-/commits/error-reporting/ (DNS error reporting PoC in Drink authoritative name server )