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

The last non-blocking COMMENT by Roman Danyliw about the section 4, i.e., `If this is human readable explanation not meant for automated processing, what is a “deliberately meaningless value”?` seems sensible.

I urge the authors to fix this COMMENT.

Thanks again for the work done by the authors and the DNSOP WG,

-éric

[Ballot comment]
Thank you to Stewart Bryant for the GENART review.

Thank you for addressing my DISCUSS feedback and part of my COMMENT feedback.

=== Prior COMMENT feedback

** Section 3

-- Bullet #1:
        Frustrated, the end user may switch to an
        alternate network that offers no DNS filtering against malware
        and phishing, potentially compromising both security and
        privacy.
-- Bullet #2:
    Frustrated, the end
      user may resort to using insecure methods to reach the domain,
      potentially compromising both security and privacy.

Can this threat be more precisely articulated?  What is being described in bullet #1 and #2 seems like how web browsing looks in the real world.  For example, I am a student on a mobile device using the school’s Wi-Fi network but it blocks the social media site I want to use, so I switch to the cellular network.  I am employee on a restricted enterprise Wi-Fi network with a BYOD situation, but it blocks the shopping site where I want to make a purchase while  having lunch in the cafeteria, so I switch to the cellular network.  I try to access a web-site but it blocks me due to geofencing policies so I use a VPN to exit in a different geography.  This speaks nothing of users in places with censoring regimes implemented by carriers which regularly resort to alternative means of access.

** Section 4
  j: (justification)  'UTF-8'-encoded [RFC5198] human-readable
      explanation for the DNS filtering decision.
…
      Returning non-UTF-8 data, syntactically invalid content, or
      deliberately meaningless values (including empty strings)
      indicates that a DNS server is misbehaving.

If this is human readable explanation not meant for automated processing, what is a “deliberately meaningless value”?

[Ballot comment]
Thank you for addressing my discuss (although I would have appreciated an actual response so I didn't have to go searching for the change). 

My comment on Section 10.1 still stands.  While QUIC relies on the TLS handshake, it is not normally specified as 'use TLS 1.3' or later. 

Also, consider changing the RFC8446 reference to RFC9846, as it was published early this week.

-------------------------------------------
Thanks to Joe Salowey for their secdir review - and follow up messages.

Section 10.1, para 1:  DOQ is mentioned parenthetically, is QUIC (RFC9000) an acceptable transport mechanism?

[Ballot discuss]
I'm making this a discuss, but I'm happy for the authors to point me to something I've missed.  It is related to Roman's discuss, I see.

Section 10.1, para 1:  'This specification assumes the use of authenticated, integrity-protected...', but it doesn't appear to be required and/or suggested anywhere besides Security Considerations of both this draft and RFC 8914?  Is it specified somewhere else?  It seems odd to assume this sort of thing with nothing mentioned in the main body of the specification.

[Ballot comment]
Thanks to Joe Salowey for their secdir review - and follow up messages.

Section 10.1, para 1:  DOQ is mentioned parenthetically, is QUIC (RFC9000) an acceptable transport mechanism?

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-dnsop-structured-dns-error-24
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-24.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to Paul Kyzivat for the ARTART review.

And many thanks to the authors for addressing Paul's review comments.

## Comments

### New JSON Names

442        New JSON names may be defined in the future.  This section specifies
443        the requirements to take into account for such names.

IMHO, a reference to the IANA considerations section for this registry would be helpful.

[Ballot comment]
Thanks to Paul Kyzivat for multiple ARTART reviews and to the authors for resolving all the concerns.

Thanks to Benno Overeinder for the particularly helpful shepherd writeup.

[Ballot comment]
Thanks for your edits to address my previous DISCUSS ballot. A few of my comments still stand, but not enough to block the document.

### Section 4, paragraph 5
```
        Contact URIs conveyed in the "c" field MUST use URI schemes
        registered in Section 11.3.
```
I continue to think it's a bit
odd to create a registry of entries that are already in another
registry, and where client behavior is entirely gated on what values they
support in the field or not.

### Section 4, paragraph 26

Are clients required to enforce these requirements on names they don't
recognize? If so, what behavior is a client required to take when processing a
non-compliant error response? If not, why are these normative requirements?

The additional text makes clear that these requirements are intended to apply to
future specifications, but there's no enforcement mechanism or client behavior
specified here.

[Ballot comment]
Section 11.1, Structured DNS Error EDNS Option, and Section 11.5's RFC Editor note:

821 >      Notes to the RFC Editor: Please replace RFCXXXX with the RFC
822 >      number assigned to this document and "TBA1" with the value
823 >      assigned by IANA, and replace "TBD1" in Figure 3 with the value
824 >      assigned by IANA.

...

832 >    Value:  TBD

This is more of an NIT.

The placeholder in Section 11.1 is "TBD" but Figure 3 uses "TBD1" for the same
EDNS(0) Option Code, and the RFC Editor note only instructs the editor to replace
"TBD1" in Figure 3. As written, the note gives the RFC Editor no instruction to
replace the "TBD" value in Section 11.1 itself.

---

Section 11.4, New Registry for Extended DNS Sub-Error Codes, sub-error codes 1 and 2:

960 >        |  1    | Malware  | "Blocked", "Blocked | Section 5.5 of |
961 >        |        |          | by Upstream DNS    | [RFC5901]      |
962 >        |        |          | Server", "Filtered" |                |
963 >        +--------+----------+---------------------+----------------+
964 >        |  2    | Phishing | "Blocked", "Blocked | Section 5.5 of |
965 >        |        |          | by Upstream DNS    | [RFC5901]      |
966 >        |        |          | Server", "Filtered" |                |

I checked RFC 5901 Section 5.5, and it defines the FraudType attribute of an
IODEF PhraudReport, whose enumerated values happen to include "malware distribution"
and "phishing" among nine fraud-reporting categories. That section is defining values
for an incident-reporting data model, not originating general definitions of
"malware" or "phishing" as DNS-filtering categories. I am not asking for a DISCUSS
here, since the terms are in ordinary use and the registry entries are intelligible
without RFC 5901, but I would suggest the authors reconsider whether RFC 5901 is
really the right reference for these two rows, since a reader who follows the
citation to understand what "Malware" or "Phishing" means for this registry will find
an unrelated reporting schema instead.

---

Section 11.4, same table, sub-error codes 3 and 4:

968 >        |  3    | Spam    | "Blocked", "Blocked | Page 289 of    |
969 >        |        |          | by Upstream DNS    | [RFC4949]      |
970 >        |        |          | Server", "Filtered" |                |
971 >        +--------+----------+---------------------+----------------+
972 >        |  4    | Spyware  | "Blocked", "Blocked | Page 291 of    |
973 >        |        |          | by Upstream DNS    | [RFC4949]      |
974 >        |        |          | Server", "Filtered" |                |

RFC 4949 is a flat, alphabetically ordered glossary rather than a sectioned
document, which is presumably why these two rows cite page numbers instead. I was
not able to confirm pages 289 and 291 against the current RFC Editor rendering of
RFC 4949 to check that they still land on the "Spam" and "Spyware" entries. Page
numbers are tied to a specific paginated rendering and are a less stable locator
than the rest of this document's references, which all cite sections. I would ask
the authors not to use page numbers as references.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 4.2, Future JSON Names Requirements:

451 >    size.  Refer to [RFC9715] for a discusson on IP fragmentation
s/discusson/discussion/

[Ballot discuss]
Questions around the use of clear-text DNS and EXTRA-TEXT:

-- Section 5.3
  1.  If the integrity of the DNS response is not guaranteed, the DNS
      client MUST NOT act upon data in the EXTRA-TEXT field, as the
      data is vulnerable to modification by an on-path attacker.

What provides an adequate guarantee of integrity to act upon the data?  What happens if the stub resolver uses DOH, but the recursive resolver does not?

-- Section 10.1, “This specification assumes the use of authenticated, integrity-protected DNS transports (e.g., DoT, DoH, or DoQ).  Such transports MUST be based on TLS 1.3 [RFC8446] or later.”  This seems ambiguous.  Is “assuming the use of” the same thing as requiring the using of “authenticated, integrity-protected DNS transports” when the EXTRA-TEXT field is use?  If so, please be explicit. I ask because a few sections later (Section 10.4 note below) the text is unambiguous on the need for “encrypted DNS transport”.

-- (not DISCUSS feedback, here for reference) Section 10.4, “This specification requires the use of an encrypted DNS transport (e.g., DoT, DoH, or DoQ), which protects both the DNS query and the structured error response from passive observers.” This is unambiguous.  Thanks.

[Ballot comment]
Thank you to Stewart Bryant for the GENART review.

I support the DISCUSS position of Mike Bishop

** Section 1.  Editorial.
  One of the other benefits of the approach described in this document
  is to eliminate the need to "spoof" block pages for HTTPS resources.
  This is achieved since clients implementing this approach would be
  able to display a meaningful error message, and would not need to
  connect to such a block page.  This approach thus avoids the need to
  install a local root certificate authority on those IT-managed
  devices.

Given that this section discusses multiple deployment environments (e.g., enterprise, home networks) and this paragraph ends with referencing only an “IT-managed” environment, would it be appropriate to make that clearer?

OLD
  One of the other benefits of the approach described in this document
  is to eliminate the need to "spoof" block pages for HTTPS resources.

NEW
One of the other benefits of the approach described in this document is to eliminate the need to "spoof" block pages for HTTPS resources in enterprise environments.

** Section 3.  Editorial.
  Each of these methods have
  advantages and disadvantages that are discussed below:

As far as I can tell, only the disadvantages are listed in the 3 bullets under this text.  I can’t find the advantages.

** Section 3

-- Bullet #1:
        Frustrated, the end user may switch to an
        alternate network that offers no DNS filtering against malware
        and phishing, potentially compromising both security and
        privacy.
-- Bullet #2:
    Frustrated, the end
      user may resort to using insecure methods to reach the domain,
      potentially compromising both security and privacy.

Can this threat be more precisely articulated?  What is being described in bullet #1 and #2 seems like how web browsing looks in the real world.  For example, I am a student on a mobile device using the school’s Wi-Fi network but it blocks the social media site I want to use, so I switch to the cellular network.  I am employee on a restricted enterprise Wi-Fi network with a BYOD situation, but it blocks the shopping site where I want to make a purchase while  having lunch in the cafeteria, so I switch to the cellular network.  I try to access a web-site but it blocks me due to geofencing policies so I use a VPN to exit in a different geography.  This speaks nothing of users in places with censoring regimes implemented by carriers which regularly resort to alternative means of access.

** Section 3
    To eliminate the need for an end user to click
        through certificate errors, an end user may manually install a
        local root certificate on a host device.  Doing so, however, is
        also a bad security practice as it creates a security
        vulnerability that may be exploited by a MITM attack. 

What is the vulnerability being exposed?  Isn’t the device serving back this warning the enterprise’s own infrastructure? Isn’t the local root certificate from the enterprise or associated service provider?

** Section 4
  j: (justification)  'UTF-8'-encoded [RFC5198] human-readable
      explanation for the DNS filtering decision.
…
      Returning non-UTF-8 data, syntactically invalid content, or
      deliberately meaningless values (including empty strings)
      indicates that a DNS server is misbehaving.

If this is human readable explanation not meant for automated processing, what is a “deliberately meaningless value”?

[Ballot discuss]
# IESG review of draft-ietf-dnsop-structured-dns-error-23

CC @MikeBishop

## Discuss

### Section 4, paragraph 5
```
        Contact URIs conveyed in the "c" field MUST use URI schemes
        registered in Section 11.3.
```
This is presumably aimed at the security discussion in 10.2. However, it's a bit
odd to create a registry of entries that are already in another
registry. What is the expected behavior upon encountering a URI scheme not in
this registry versus one added to this registry later that the client doesn't
implement any particular behavior for?

I would consider eliminating this registry entirely and instead saying that
clients MUST/SHOULD ignore URI schemes they don't specifically support here, and
recommend these two be the only ones supported.

### Section 4, paragraph 15
```
    is returned.  The "s" field MUST convey the primary blocking cause.
    The "j" field MUST be used to provide additional context describing
    all applicable causes.
```
What is the relative priority between an optional field that MUST convey certain
information? That is, should this be read as "MUST ... if present" or as "MUST
be present and ..."?

### Section 4, paragraph 26

Are clients required to enforce these requirements on names they don't
recognize? If so, what behavior is a client required to take when processing a
non-compliant error response? If not, why are these normative requirements?

### Section 10.2, paragraph 6

There are currently 66,149 such organizations. Are clients expected to
check against the list in real-time or embed the list in their code? What is the
guarantee that these organizations are trusted?

### Section 10.2, paragraph 7

How does the client determine the intent of a text string?

[Ballot comment]
## Comments

### Section 3, paragraph 2

These are very long bullet points. Might they be easier to digest as
subsections?

### Section 3, paragraph 2
```
        the host component [RFC3986] of an HTTP URL is blocked, the
        network security device (e.g., Customer Premises Equipment (CPE)
        or firewall) presents a block page instead of the HTTP response
        from the content provider hosting that domain.  This works
        successfully with HTTP.
```
I'm unclear why this is scoped to "if the host component is blocked." The host
is the only thing there is at the DNS layer. Or are you trying to say this
technique could be used to insert a proxy in the middle to perform more granular
path-based filtering on a given site?

### Section 4, paragraph 12

It seems odd to say a field can be omitted entirely, but cannot be
empty.

### Section 5.2, paragraph 4

The second MAY is not normative; perhaps "might" or "could"?

### Section 10.3, paragraph 1

"from" => "only from"?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 7
```
-    [RFC8914] which says the information in EXTRA-TEXT field is intended
+    [RFC8914], which says the information in EXTRA-TEXT field is intended
+            +
```

#### Section 4, paragraph 23
```
-    To avoid exceeding the maximum EDNS0 size [RFC9715] the generated
+    To avoid exceeding the maximum EDNS0 size [RFC9715], the generated
+                                                      +
```

#### Section 5.2, paragraph 4
```
-    Servers MAY decide to return small TTL values in filtered DNS
-              ----------
```

#### Section 5.3, paragraph 4
```
-        client MUST treat the data as invalid, MUST NOT process it
-                                            ^
+        client MUST treat the data as invalid and MUST NOT process it
+                                            ^^^^
```

### Section 5.1, paragraph 2
```
    The presence of the SDE option indicates that the client desires the
    DNS server to include an EDE option in the DNS response when DNS
    filtering is performed, and that any data conveyed in the EXTRA-TEXT
    field of the EDE option is encoded and processed in accordance with
    this specification.
```
The client desires ... that any data ... is ... processed in accordance with
this specification, but the client is the one doing the processing. Rephrase
that part as the client advising the server that it will attempt to process any
such data according to this specification. (Or desires that it *can be* so
processed.)

[Ballot comment]
FYI#1: as Med is a co-author, he asked me to be the responsible AD for this DNSOP draft

FYI#2: a first version of this I-D failed the IETF Last Call, and I returned it the I-D to the DNSOP WG

FYI#3: while the 2nd WGLC/IETF LC got consensus, there were some discussions about the usefulness of the human-readable string as it may not be displayed by browsers.

[Ballot comment]
FYI#1: as Med is a co-author, he asked me to be the responsible AD for this DNSOP draft

FYI#2: a first version of this I-D failed the IETF Last Call, and I returned the I-D to the DNSOP WG

FYI#3: while the 2nd WGLC/IETF LC got consensus, there were some discussion about the usefulness/security of the human-readable string as it may not be displayed by browsers.

IESG/Authors/WG Chairs:

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

IANA understands that, upon approval of this document, there are five actions that 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 will be made as follows:

Value: [ TBD-at-registration ]
Name: Structured DNS Error
Status: Standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

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

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

The new registry is to be managed via IETF Review as defined in [RFC8126]. There are initial registrations in the new registry as follows:

JSON Name: c
Field Meaning: contact
Description: The contact details of the IT/InfoSec team to report misclassified DNS filtering
Reference: [ RFC-to-be; Section 4 ]

JSON Name: j
Field Meaning: justification
Description: UTF-8-encoded [RFC5198] textual justification for a particular DNS filtering
Reference: [ RFC-to-be; Section 4 ]

JSON Name: s
Field Meaning: sub-error
Description: Integer representing the sub-error code for this DNS filtering case
Reference: [ RFC-to-be; Section 4 ]

JSON Name: o
Field Meaning: organization
Description: UTF-8-encoded human-friendly name of the organization that filtered this particular DNS query
Reference: [ RFC-to-be; Section 4 ]

JSON Name: l
Field Meaning: language
Description: Indicates the language of the "j" and "o" fields as defined in [RFC5646]
Reference: [ RFC-to-be; Section 4 ]

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

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

The new registry is to be managed via IETF Review as defined in [RFC8126]. There are initial registrations in the new registry as follows:

Name: sips
Meaning: SIP Call
Reference: [rfc5630]

Name: tel
Meaning: Telephone Number
Reference: [rfc3966]

Name: mailto
Meaning: Internet Mail
Reference: [rfc6068]

Fourth, a new registry is to be created called the Sub-Error Codes registry under "Extended DNS Error Codes" registry in the Domain Name System (DNS) Parameters registry group located at:

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

The new registry is to be managed via IETF Review as defined in [RFC8126]. There are initial registrations in the new registry as follows:

Number: 0
Meaning: Reserved
EDE Codes Applicability: Not used
Reference: [ RFC-to-be; Section 6.1 ]

Number: 1
Meaning: Malware
EDE Codes Applicability: "Blocked", "Blocked by Upstream DNS Server", "Filtered"
Reference: [RFC5901; Section 5.5]

Number: 2
Meaning: Phishing
EDE Codes Applicability: "Blocked", "Blocked by Upstream DNS Server", "Filtered"
Reference: [RFC5901; Section 5.5]

Number: 3
Meaning: Spam
EDE Codes Applicability: "Blocked", "Blocked by Upstream DNS Server", "Filtered"
Reference: [RFC4949; Page 289]

Number: 4
Meaning: Spyware
EDE Codes Applicability: "Blocked", "Blocked by Upstream DNS Server", "Filtered"
Reference: [RFC4949; Page 291]

Number: 5
Meaning: Network operator policy
EDE Codes Applicability: "Blocked"
Reference: [ RFC-to-be; Section 6.2 ]

Number: 6
Meaning: DNS operator policy
EDE Codes Applicability: "Blocked"
Reference: [ RFC-to-be; Section 6.3 ]

Fifth, 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 DNS 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 2026-06-23):

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 2026-06-23. 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.

Note: this is the second IETF Last Call for this document as the
first IETF Last Call (May 2025) did not get consensus. Read the shepherd's
write-up for more information.

Abstract


  DNS filtering is widely deployed for various reasons, including
  network security and policy enforcement.  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.

Per https://mailarchive.ietf.org/arch/msg/dnsop/dc44LiyvcoBlq48XRASZ9MaCDzQ/ :

After reading the multiple email threads about my request to add some human language negotiation, it appears that my request is both useless (human-readable text will never be displayed by browsers) and has no consensus within the WG.

Dear authors, would you mind re-submitting a revised I-D that removes the language negotiation (i.e., sections 5.1, 5.2,  5.4, 11.1).

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.

The draft does not conflict with other documents in the DNSOP or other working groups that specify work related to or aligned with the draft.  See the Working Group Summary below for more information.


(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.  The draft makes the filtering-related information machine-readable and safer to use, especially in HTTPS contexts.  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, in 2020, the draft encountered substantial objections within the DNSOP Working Group.  The authors iteratively improved the document based on feedback from WG discussions, and over time it gained support from several industry stakeholders.  Following the first Working Group Last Call (WGLC), the WG concluded that consensus had been reached.

However, during IETF Last Call, concerns were raised by participants from the Security Area, as well as potential misalignment with the related draft draft-nottingham-dnsop-censorship-transparency.

The draft was therefore returned to the DNSOP Working Group, and a virtual interim meeting was held to address the feedback and alignment issues. This led to further revisions and a second, extended WGLC, during which constructive discussion resulted in additional improvements to the document.

Document Quality:

As part of the protocol design, a proof-of-concept implementation and demo were presented by Gianpaolo Scalone and Ralf Weber during the DNSOP WG sessions at IETF 116. Several vendors have since indicated their intention to implement the standard in their products, and operators have expressed interest in deploying it within their network services.

Following the virtual interim and second WGLC, the document received thorough DNS Directorate review, as well as additional input from participants who had raised concerns during IETF Last Call.  The document has been updated accordingly and there are no conflicts between other ongoing related work.

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.


(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 a number of directorate reviews, among which a multiple 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.

No issues found here.


(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)?

No issues found here.


(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.  Having Proposed Standard status will help support implementation and adoption.

The draft does not conflict with other documents in the DNSOP or other working groups that specify work related to or aligned with the draft.  See the Working Group Summary below for more information.


(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.  The draft makes the filtering-related information machine-readable and safer to use, especially in HTTPS contexts.  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, in 2020, the draft encountered substantial objections within the DNSOP Working Group.  The authors iteratively improved the document based on feedback from WG discussions, and over time it gained support from several industry stakeholders.  Following the first Working Group Last Call (WGLC), the WG concluded that consensus had been reached.

However, during IETF Last Call, concerns were raised by participants from the Security Area, as well as potential misalignment with the related draft draft-nottingham-dnsop-censorship-transparency.

The draft was therefore returned to the DNSOP Working Group, and a virtual interim meeting was held to address the feedback and alignment issues. This led to further revisions and a second, extended WGLC, during which constructive discussion resulted in additional improvements to the document.

Document Quality:

As part of the protocol design, a proof-of-concept implementation and demo were presented by Gianpaolo Scalone and Ralf Weber during the DNSOP WG sessions at IETF 116. Several vendors have since indicated their intention to implement the standard in their products, and operators have expressed interest in deploying it within their network services.

Following the virtual interim and second WGLC, the document received thorough DNS Directorate review, as well as additional input from participants who had raised concerns during IETF Last Call.  The document has been updated accordingly and there are no conflicts between other ongoing related work.

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.


(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 a number of directorate reviews, among which a multiple 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.

No issues found here.


(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)?

No issues found here.


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

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.