Hi Petr On Fri, Mar 20, 2026 at 04:54:39PM +0100, Petr Špaček wrote: > On 20. 03. 26 4:03, Mukund Sivaraman wrote: > > I am attempting to implement support for Structured DNS Error on a > > branch. Some questions as it's not clear from the draft: > > > > (1) When a client queries with the EDNS SDE option in the query, what is > > the server behavior when there is a non-filtered non-other EDE response? > > For example, if the EDE INFO-CODE is "Unsupported NSEC3 Iterations > > Value" (27) or "Rate Limited" (28), should a plain RFC 8914 option be > > returned or a structured DNS error be returned with the "j" (and > > optionally "c" and "o") fields populated? > > Indeed that's a good question. I have not considered that possibility. > > The question is how real it is. If the query was blocked (which would cause > the SDE to be generated), should other EDEs even be sent back at all? > > I don't know. You've opened whole new can of worms.
On this topic, in the RFC notes chapter of the Loop user manual, I've
made the following notes for this draft that describes how Loop will
handle different cases:
> When it is enabled, the Structured Error Data for Filtered DNS JSON is
> returned in the EDNS Extended DNS Error option in responses only when
> blocking/filtering/censoring is performed and negative responses are
> generated. When blocking/filtering/censoring is not performed, or when
> negative responses are not generated due to their actions, the regular
> :rfc:`8914` Extended DNS Error option is returned.
> When RPZ processing is performed for a query and when the triggered RPZ
> policy action causes a "Local Data" action to be applied such as a CNAME
> or address record, a regular :rfc:`8914` Extended DNS Error option is
> returned (if enabled) in the response to the query with INFO-CODE set to
> *Forged Answer* (4). No Structured Error Data for Filtered DNS JSON is
> returned as the latter draft forbids forged answers. This is the case
> even if the forged answer was generated due to the result of
> blocking/filtering/censoring action.
This can be understood from what is written in the draft, but the draft
is written in a very roundabout way from how I read it.. it may be
because my mind is wired against what's in the draft.
In Loop, RPZ blocking/filtering/censoring action implies NXDOMAIN/NODATA
response for which plain EDE is currently returned. We return "Forged
Answer" for "Local Data" policy actions such as returning an address
record. It appears this draft does not want to deal with forged answers
at all (due to the TLS certificate mismatch with HTTPS servers), so no
structured JSON is going to be returned for those cases.
BTW, in Loop's named.conf we use an "intent" clause in each RPZ zone
that can be used to pick whether the zone's NX policy actions are
blocking/filtering/censoring to return in EDE. Something like:
response-policy {
zone "rpz1.example.com"; /* no intent provided */
zone "rpz2.example.com" intent blocking;
zone "rpz3.example.com" intent censoring;
zone "rpz4.example.com" intent filtering;
} recursive-only no;
I hope this fits in to make the above notes clearer.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
