Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2025-01-29
10 Benno Overeinder
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 …
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.

2025-01-29
10 Benno Overeinder IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2025-01-29
10 Benno Overeinder IESG state changed to Publication Requested from I-D Exists
2025-01-29
10 (System) Changed action holders to Warren Kumari (IESG state changed)
2025-01-29
10 Benno Overeinder Responsible AD changed to Warren Kumari
2025-01-29
10 Benno Overeinder Document is now in IESG state Publication Requested
2025-01-29
10 Benno Overeinder
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 …
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.

2024-12-03
10 Benno Overeinder IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2024-11-26
10 Tirumaleswar Reddy.K New version available: draft-ietf-dnsop-structured-dns-error-10.txt
2024-11-26
10 Tirumaleswar Reddy.K New version accepted (logged-in submitter: Tirumaleswar Reddy.K)
2024-11-26
10 Tirumaleswar Reddy.K Uploaded new revision
2024-10-26
09 Benno Overeinder IETF WG state changed to In WG Last Call from WG Document
2024-10-26
09 Benno Overeinder Notification list changed to benno@NLnetLabs.nl because the document shepherd was set
2024-10-26
09 Benno Overeinder Document shepherd changed to Benno Overeinder
2024-10-26
09 Benno Overeinder Changed consensus to Yes from Unknown
2024-10-26
09 Benno Overeinder Intended Status changed to Proposed Standard from None
2024-07-28
09 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-09.txt
2024-07-28
09 Mohamed Boucadair New version approved
2024-07-28
09 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2024-07-28
09 Dan Wing Uploaded new revision
2024-01-31
08 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-08.txt
2024-01-31
08 Mohamed Boucadair New version approved
2024-01-31
08 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2024-01-31
08 Dan Wing Uploaded new revision
2023-11-05
07 Tirumaleswar Reddy.K New version available: draft-ietf-dnsop-structured-dns-error-07.txt
2023-11-05
07 Tirumaleswar Reddy.K New version accepted (logged-in submitter: Tirumaleswar Reddy.K)
2023-11-05
07 Tirumaleswar Reddy.K Uploaded new revision
2023-07-26
06 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-06.txt
2023-07-26
06 Mohamed Boucadair New version approved
2023-07-26
06 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2023-07-26
06 Dan Wing Uploaded new revision
2023-07-07
05 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-05.txt
2023-07-07
05 Mohamed Boucadair New version approved
2023-07-07
05 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2023-07-07
05 Dan Wing Uploaded new revision
2023-07-05
04 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-04.txt
2023-07-05
04 Mohamed Boucadair New version approved
2023-07-05
04 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2023-07-05
04 Dan Wing Uploaded new revision
2023-06-30
03 Joseph Salowey Request for Early review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. Sent review to list. Submission of review completed at an earlier date.
2023-06-30
03 Joseph Salowey Request for Early review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey.
2023-06-29
03 Matt Brown Request for Early review by DNSDIR Completed: Almost Ready. Reviewer: Matt Brown. Sent review to list.
2023-06-27
03 Di Ma Request for Early review by DNSDIR Completed: Ready. Reviewer: Di Ma. Review has been revised by Di Ma.
2023-06-25
03 Di Ma Request for Early review by DNSDIR Completed: Ready with Nits. Reviewer: Di Ma. Sent review to list. Submission of review completed at an earlier date.
2023-06-25
03 Di Ma Request for Early review by DNSDIR Completed: Ready with Nits. Reviewer: Di Ma.
2023-06-01
03 Tero Kivinen Closed request for Early review by SECDIR with state 'Withdrawn'
2023-06-01
03 Tero Kivinen Request for Early review by SECDIR is assigned to Joseph Salowey
2023-05-30
03 Jim Reid Request for Early review by DNSDIR is assigned to Matt Brown
2023-05-30
03 Jim Reid Request for Early review by DNSDIR is assigned to Di Ma
2023-05-30
03 Tim Wicinski Requested Early review by DNSDIR
2023-05-30
03 Tim Wicinski Requested Early review by SECDIR
2023-05-30
03 Tim Wicinski Requested Early review by DNSDIR
2023-05-30
03 Tim Wicinski Requested Early review by SECDIR
2023-05-26
03 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-03.txt
2023-05-26
03 Dan Wing New version approved
2023-05-26
03 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook , dnsop-chairs@ietf.org
2023-05-26
03 Dan Wing Uploaded new revision
2023-05-26
03 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2023-05-26
03 Dan Wing Uploaded new revision
2023-04-29
02 Tirumaleswar Reddy.K New version available: draft-ietf-dnsop-structured-dns-error-02.txt
2023-04-29
02 (System) New version approved
2023-04-29
02 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , Neil Cook
2023-04-29
02 Tirumaleswar Reddy.K Uploaded new revision
2023-03-28
01 Benno Overeinder Added to session: IETF-116: dnsop  Thu-0030
2023-03-26
01 Tirumaleswar Reddy.K New version available: draft-ietf-dnsop-structured-dns-error-01.txt
2023-03-26
01 Tirumaleswar Reddy.K New version accepted (logged-in submitter: Tirumaleswar Reddy.K)
2023-03-26
01 Tirumaleswar Reddy.K Uploaded new revision
2023-02-16
00 Tim Wicinski Changed document external resources from:

github_repo https://ietf-wg-dnsop.github.io/draft-ietf-dnsop-structured-dns-error

to:

github_repo https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error
2023-02-16
00 Tim Wicinski Changed document external resources from: None to:

github_repo https://ietf-wg-dnsop.github.io/draft-ietf-dnsop-structured-dns-error
2023-02-14
00 Jenny Bui This document now replaces draft-wing-dnsop-structured-dns-error-page instead of None
2023-02-13
00 Dan Wing New version available: draft-ietf-dnsop-structured-dns-error-00.txt
2023-02-13
00 Benno Overeinder WG -00 approved
2023-02-13
00 Dan Wing Set submitter to "Dan Wing ", replaces to (none) and sent approval email to group chairs: dnsop-chairs@ietf.org
2023-02-13
00 Dan Wing Uploaded new revision