Hi Stephane,
Thanks for the review, please see inline
On Thu, 24 Apr 2025 at 19:25, Stephane Bortzmeyer <bortzmeyer=40nic.fr@xxxxxxxxxxxxxx> wrote:
On Mon, Apr 14, 2025 at 08:18:29AM -0700,
The IESG <iesg-secretary@xxxxxxxx> wrote
a message of 28 lines which said:
> 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'
> <draft-ietf-dnsop-structured-dns-error-12.txt> as Proposed Standard
[Review based on the more recent -13.]
The draft seems basically OK to me. However, a few remarks.
1) The EDE code 16 - Censored has been… censored :-) The draft
mentions only EDE 4, 15 and 17, not 16 and I do not see in the
archives why.
The sub-error codes defined in the draft are not relevant for "Censored", other fields could be returned with this EDE, updated draft for clarity.
2)
> If EDE support is signaled in the query as per Section 5.1, the
> server MUST NOT return the "Forged Answer" extended error code
> because the client can take advantage of EDE's more sophisticated
> error reporting (e.g., "Filtered", "Blocked").
I do not understand the reason for this choice. I find no discussion
in the mailing list.
If a "Forged Answer" is returned, sub-error codes such as "malware" cannot be used, as these sub-error codes are associated with extended error codes like "Filtered" and "Blocked" (see https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-14.html#section-11.3) for details.
3)
> 5. If the "c" field contains any URI scheme not registered in the
> Section 11.2 registry, **that field** MUST be discarded.
The "c" field can contain several contact points. Does the text mean
that all should be discarded or only the contact point with the
unregistered scheme?
"c": [
"tel:+358-555-1234567",
"frobnicate:foobar.example"
],
In that example, it seems we should be able to use the "tel"
URI. Otherwise, it will be impossible to deploy new schemes, because
they would break processing by old servers.
Good point, update text as follows:
If the "c" field contains any contact URIs that use a scheme not registeredin the {{IANA-Contact}} registry, only those URIs MUST be discarded. Contact
URIs using registered schemes can be processed.
4) This example:
{
"c": [
"tel:+358-555-1234567",
"sips:bob@xxxxxxxxxxxxxxxxxxxx"
],
"j": "malware present for 23 days",
"s": 1,
"o": "example.net Filtering Service",
"l": "tzm"
}
"j" seems in english but the language tag indicates Central Atlas
Tamazight.
Thanks, fixed.
5) Table 1: Initial JSON Names Registry
Optional fields have a "N" but "l" (language) has "No". Is there a
semantic difference? ("l" is recommended, unlike the others.)
It was a typo, fixed.
6) Interoperation with RPZ Servers
I do not understand why they need a special appendix. The fact that a
resolver blocks/filters/forges from a RPZ feed or from manual
configuration should be irrelevant, no?
The intent behind including an appendix on RPZ servers (which are widely deployed today) is not to treat them as special, but to provide practical guidance for implementers who may wish to map RPZ policy actions (such as
NXDOMAIN) to structured error data. -Tiru
_______________________________________________
DNSOP mailing list -- dnsop@xxxxxxxx
To unsubscribe send an email to dnsop-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
