On Fri, Mar 20, 2026 at 03:03:53AM +0000, 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?
>
> (2) From the draft:
>
> > If the query includes the SDE option 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"). Continuing to send "Forged Answer" even
> > to an EDE-supporting client will cause the persistence of the
> > drawbacks described in Section 3.
>
> What INFO-CODE instead of 4 (Forged Answer) does the server return in
> this case alongside the JSON EXTRA-TEXT?
>
> Or is this RFC stating that a plain RFC 8914 EXTRA-TEXT must not be
> returned?
Nevermind, I misread the text. When a client queries with SDE, the draft
appears to state Filtered or Blocked in the INFO-CODE and never to
returns "Forged Answer".
Loop currently returns "Forged Answer" in the EDE option in one case:
for RPZ rewrites where the policy action is a record. The existing RFC
8194 INFO-CODES Filtered, Blocked and Censored would not apply to such a
response, because these state "The server is unable to respond..."
implying they are meant to be used in responses where there is no answer
and the RCODE is NXDOMAIN or NODATA.
Would Censored be the INFO-CODE that this draft wants us to use in this
case? From RFC 8194:
> 4.17. Extended DNS Error Code 16 - Censored
> The server is unable to respond to the request because the domain is
> on a blocklist due to an external requirement imposed by an entity
> other than the operator of the server resolving or forwarding the
> query. Note that how the imposed policy is applied is irrelevant
> (in-band DNS filtering, court order, etc.).
Mukund
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
