Structured Error Data for Filtered DNS
draft-ietf-dnsop-structured-dns-error-15

IESG/Authors/WG Chairs:

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

IANA also has a question about the new registries being created.

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

First, a new registry is to be created called the EXTRA-TEXT JSON Names registry. The new registry will be created in the Domain Name System (DNS) Parameters registry group located at:

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

The registration procedure for the entire registry is IETF Review as defined in RFC8126. There are initial registrations in the new registry as follows:

JSON Name Field Meaning Description Mandatory Reference
------------+-------------+-----------+-----------+----------
c contact The contact details of the IT/InfoSec team to report mis-classified DNS filtering Y [ RFC-to-be; Section 4 ]
j justification UTF-8-encoded [RFC5198] textual justification for a particular DNS filtering Y [ RFC-to-be; Section 4 ]
s suberror the suberror code for this particular DNS filtering N [ RFC-to-be; Section 4 ]
o organization UTF-8-encoded human-friendly name of the organization N [ RFC-to-be; Section 4 ]
l language Indicates the language of the "j" and "o" fields as defined in [RFC5646] N [ RFC-to-be; Section 4 ]

IANA Question -> Are these three registries to be created as sub-registries under the Extended DNS Error Codes registry in the Domain Name System (DNS) Parameters registry group (https://www.iana.org/assignments/dns-parameters/), or are they to be separate registries in the registry group?

Second, a new registry is to be created called the Contact URI Schemes registry. The new registry will be created in the Domain Name System (DNS) Parameters registry group located at:

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

The registration procedure for the entire registry is IETF Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Name Meaning Reference Change Controller
------+--------+----------+-----------------
sips SIP Call [RFC5630] IETF
tel Telephone Number [RFC3966] IETF
mailto Internet mail [RFC6068] IETF

Third, a new registry is to be created called the Sub-Error Codes registry. The new registry will be created in the Domain Name System (DNS) Parameters registry group located at:

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

The registration procedure for the entire registry is IETF Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Number Meaning EDE Codes Applicability Reference Change Controller
--------+--------+-----------------------+----------+-------------------
0 Reserved Not used [ RFC-to-be; Section 7.1 ] IETF
1 Malware "Blocked", "Blocked by Upstream Server", "Filtered" [RFC5901; Section 5.5] IETF
2 Phishing "Blocked", "Blocked by Upstream Server", "Filtered" [RFC5901; Section 5.5] IETF
3 Spam "Blocked", "Blocked by Upstream Server", "Filtered" [RFC4949; Section 4] IETF
4 Spyware "Blocked", "Blocked by Upstream Server", "Filtered" [RFC4949; Section 4] IETF
5 Network operator policy "Blocked" [ RFC-to-be; Section 7.2 ] IETF
6 DNS operator policy "Blocked" [ RFC-to-be; Section 7.2 ] IETF

Fourth, in the Extended DNS Error Codes registry also in the Domain Name System (DNS) Parameters registry group located at:

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

a single new registration will be made as follows:

INFO-CODE: [ TBD-at-Registration ]
Purpose: Blocked by Upstream Server
Reference: [ RFC-to-be ]

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 2025-04-28):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-structured-dns-error@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Structured Error Data for Filtered DNS) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Structured Error Data for
Filtered DNS'
  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 2025-04-28. 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 filtering is widely deployed for various reasons, including
  network security.  However, filtered DNS responses lack structured
  information for end users to understand the reason for the filtering.
  Existing mechanisms to provide explanatory details to end users cause
  harm especially if the blocked DNS response is for HTTPS resources.

  This document updates RFC 8914 by signaling client support for
  structuring the EXTRA-TEXT field of the Extended DNS Error to provide
  details on the DNS filtering.  Such details can be parsed by the
  client and displayed, logged, or used for other purposes.




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



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

draft-ietf-dnsop-structured-dns-error

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

The draft-ietf-dnsop-structured-dns-error has the intended status of Proposed Standard.  This is the correct status for the document as it specifies an update to RFC 8914 by providing additional details on DNS filtering.  This document does not recommend DNS filtering, but provides a mechanism for greater transparency to explain to users why some DNS queries are filtered.  Having Proposed Standard status will help support implementation and adoption.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

DNS filtering is commonly used for purposes such as enhancing network security.  However, when DNS responses are filtered, they often do not provide users with clear, structured information explaining why the filtering occurred.  Existing methods for sharing such details can inadvertently cause issues, particularly when the blocked DNS response involves HTTPS resources.

This document proposes an update to RFC 8914, introducing a mechanism to structure the EXTRA-TEXT field of the Extended DNS Error (EDE).  This allows clients to signal their support for receiving detailed explanations about DNS filtering.  These details can then be parsed by the client and utilized in various ways, such as displaying them to users, logging the information, or applying it for other purposes.

Working Group Summary: 

Initially, the draft did not receive significant enthusiasm within the DNSOP Working Group due to some fundamental objections to its early revisions.  However, the authors consistently improved the document based on feedback from DNSOP WG discussions during sessions and on the mailing list.  Over time, the draft gained support from several industry stakeholders.  During the thorough process in the DNSOP WG, with multiple iterations of the document and ample feedback from the working group, we can conclude that the WG reached consensus on the latest revision submitted to the IESG.

Document Quality:

As part of the protocol design specified in the draft, a proof-of-concept implementation and a demo were presented by Gianpaolo Scalone (Vodafone) and Ralf Weber (Akamai) during the DNSOP WG sessions at IETF 116.  Some vendors have explicitly stated that they want to implement the standard in their products, and operators want to use it in their network services.

Personnel:

The Document Shepherd is Benno Overeinder and Éric Vyncke is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

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.

Typo: occured -> occurred
Typo: Purose -> Purpose
Typo: " each IT teams.  Returning garbage data would indicate that a DNS"
      s/ each IT teams/ each IT team/


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of the reviews.


(5) Do portions of the document need review from a particular or from a broader perspective.

There has been one SECDIR and two DNSDIR reviews of the document at the request of the DNSOP WG chairs.  All comments were incorporated or discussed on the mailing list to reach agreement.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

The Document Shepherd has no concerns about the document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There is no IPR.


(8) Has an IPR disclosure been filed that references this document?

There is no IPR.


(9) How solid is the WG consensus behind this document?

There was a solid consensus on the document.  During the process, feedback from the WG was shared with the authors, who incorporated it or discussed it on the mailing to reach agreement.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

There have been no appeals.


(11) Identify any ID nits the Document Shepherd has found in this document.

There are still some idnits to be resolved:
  ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
  This is explained in the text with historical context, so fine.

  -- Obsolete informational reference (is this intentional?): RFC 8499
    (Obsoleted by RFC 9499)
  This should be updated by the authors.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review is required.


(13) Have all references within this document been identified as either normative or informative?

All references have been identified as normative or informative.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are in a clear state.


(15) Are there downward normative references (see RFC 3967)?

From the nits:
** Downref: Normative reference to an Informational RFC: RFC 4949

Terms defined in RFC 4949 are used side by side (in a table) with other terms from Standards Track RFCs.  So it can be argued that RFC 4949 should also be a normative reference.


(16) Will publication of this document change the status of any existing RFCs?

This RFC will not change any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

The IANA section of the document correctly requests the assignment of an extended DNS error code from the Domain Name System (DNS) Parameters, Extended DNS Error Codes registry. 


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There is no new IANA registry requested.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not relevant.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?

There is no YANG module.

draft-ietf-dnsop-structured-dns-error

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

The draft-ietf-dnsop-structured-dns-error has the intended status of Proposed Standard.  This is the correct status for the document as it specifies an update to RFC 8914 by providing additional details on DNS filtering.  This document does not recommend DNS filtering, but provides a mechanism for greater transparency to explain to users why some DNS queries are filtered.  The status of Proposed Standard will


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

DNS filtering is commonly used for purposes such as enhancing network security.  However, when DNS responses are filtered, they often do not provide users with clear, structured information explaining why the filtering occurred.  Existing methods for sharing such details can inadvertently cause issues, particularly when the blocked DNS response involves HTTPS resources.

This document proposes an update to RFC 8914, introducing a mechanism to structure the EXTRA-TEXT field of the Extended DNS Error (EDE).  This allows clients to signal their support for receiving detailed explanations about DNS filtering.  These details can then be parsed by the client and utilized in various ways, such as displaying them to users, logging the information, or applying it for other purposes.

Working Group Summary: 

Initially, the draft did not receive significant enthusiasm within the DNSOP Working Group due to some fundamental objections to its early revisions.  However, the authors consistently improved the document based on feedback from DNSOP WG discussions during sessions and on the mailing list.  Over time, the draft gained support from several industry stakeholders.  During the thorough process in the DNSOP WG, with multiple iterations of the document and ample feedback from the working group, we can conclude that the WG reached consensus on the latest revision submitted to the IESG.

Document Quality:

As part of the protocol design specified in the draft, a proof-of-concept implementation and a demo were presented by Gianpaolo Scalone (Vodafone) and Ralf Weber (Akamai) during the DNSOP WG sessions at IETF 116.  Some vendors have explicitly stated that they want to implement the standard in their products, and operators want to use it in their network services.

Personnel:

The Document Shepherd is Benno Overeinder and Warren Kumari is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

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.

Typo: occured -> occurred
Typo: Purose -> Purpose
Typo: " each IT teams.  Returning garbage data would indicate that a DNS"
      s/ each IT teams/ each IT team/


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of the reviews.


(5) Do portions of the document need review from a particular or from a broader perspective.

There has been one SECDIR and two DNSDIR reviews of the document at the request of the DNSOP WG chairs.  All comments were incorporated or discussed on the mailing list to reach agreement.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

The Document Shepherd has no concerns about the document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There is no IPR.


(8) Has an IPR disclosure been filed that references this document?

There is no IPR.


(9) How solid is the WG consensus behind this document?

There was a solid consensus on the document.  During the process, feedback from the WG was shared with the authors, who incorporated it or discussed it on the mailing to reach agreement.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

There have been no appeals.


(11) Identify any ID nits the Document Shepherd has found in this document.

There are still some idnits to be resolved:
  ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
  This is explained in the text with historical context, so fine.

  -- Obsolete informational reference (is this intentional?): RFC 8499
    (Obsoleted by RFC 9499)
  This should be updated by the authors.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review is required.


(13) Have all references within this document been identified as either normative or informative?

All references have been identified as normative or informative.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are in a clear state.


(15) Are there downward normative references (see RFC 3967)?

From the nits:
** Downref: Normative reference to an Informational RFC: RFC 4949

Terms defined in RFC 4949 are used side by side (in a table) with other terms from Standards Track RFCs.  So it can be argued that RFC 4949 should also be a normative reference.


(16) Will publication of this document change the status of any existing RFCs?

This RFC will not change any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

The IANA section of the document correctly requests the assignment of an extended DNS error code from the Domain Name System (DNS) Parameters, Extended DNS Error Codes registry. 


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There is no new IANA registry requested.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not relevant.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?

There is no YANG module.

draft-ietf-dnsop-structured-dns-error

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

The draft-ietf-dnsop-structured-dns-error has the intended status of Proposed Standard.  This is the correct status for the document as it specifies an update to RFC 8914 by providing additional details on DNS filtering.  This document does not recommend DNS filtering, but provides a mechanism for greater transparency to explain to users why some DNS queries are filtered.  The status of Proposed Standard will


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

DNS filtering is commonly used for purposes such as enhancing network security.  However, when DNS responses are filtered, they often do not provide users with clear, structured information explaining why the filtering occurred.  Existing methods for sharing such details can inadvertently cause issues, particularly when the blocked DNS response involves HTTPS resources.

This document proposes an update to RFC 8914, introducing a mechanism to structure the EXTRA-TEXT field of the Extended DNS Error (EDE).  This allows clients to signal their support for receiving detailed explanations about DNS filtering.  These details can then be parsed by the client and utilized in various ways, such as displaying them to users, logging the information, or applying it for other purposes.

Working Group Summary: 

Initially, the draft did not receive significant enthusiasm within the DNSOP Working Group due to some fundamental objections to its early revisions.  However, the authors consistently improved the document based on feedback from DNSOP WG discussions during sessions and on the mailing list.  Over time, the draft gained support from several industry stakeholders.  During the thorough process in the DNSOP WG, with multiple iterations of the document and ample feedback from the working group, we can conclude that the WG reached consensus on the latest revision submitted to the IESG.

Document Quality:

As part of the protocol design specified in the draft, a proof-of-concept implementation and a demo were presented by Gianpaolo Scalone (Vodafone) and Ralf Weber (Akamai) during the DNSOP WG sessions at IETF 116.  Some vendors have explicitly stated that they want to implement the standard in their products, and operators want to use it in their network services.

Personnel:

The Document Shepherd is Benno Overeinder and Warren Kumari is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

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.

Typo: occured -> occurred
Typo: Purose -> Purpose
Typo: " each IT teams.  Returning garbage data would indicate that a DNS"
      s/ each IT teams/ each IT team/


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breadth of the reviews.


(5) Do portions of the document need review from a particular or from a broader perspective.

There has been one SECDIR and two DNSDIR reviews of the document at the request of the DNSOP WG chairs.  All comments were incorporated or discussed on the mailing list to reach agreement.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

The Document Shepherd has no concerns about the document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There is no IPR.


(8) Has an IPR disclosure been filed that references this document?

There is no IPR.


(9) How solid is the WG consensus behind this document?

There was a solid consensus on the document.  During the process, feedback from the WG was shared with the authors, who incorporated it or discussed it on the mailing to reach agreement.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

There have been no appeals.


(11) Identify any ID nits the Document Shepherd has found in this document.

There are still some idnits to be resolved:
  ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
  This is explained in the text with historical context, so fine.

  -- Obsolete informational reference (is this intentional?): RFC 8499
    (Obsoleted by RFC 9499)
  This should be updated by the authors.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review is required.


(13) Have all references within this document been identified as either normative or informative?

All references have been identified as normative or informative.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are in a clear state.


(15) Are there downward normative references (see RFC 3967)?

From the nits:
** Downref: Normative reference to an Informational RFC: RFC 4949

Terms defined in RFC 4949 are used side by side (in a table) with other terms from Standards Track RFCs.  So it can be argued that RFC 4949 should also be a normative reference.


(16) Will publication of this document change the status of any existing RFCs?

This RFC will not change any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

The IANA section of the document correctly requests the assignment of an extended DNS error code from the Domain Name System (DNS) Parameters, Extended DNS Error Codes registry. 


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There is no new IANA registry requested.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not relevant.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?

There is no YANG module.