[DNSOP] Re: Comments from IETF Last Call about draft-ietf-dnsop-structured-dns-error

[Petr Špaček <[e-mail]>]

On 5/6/25 10:28, tirumal reddy wrote:
> On Mon, 5 May 2025 at 21:23, Petr Špaček <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On 5/5/25 17:27, tirumal reddy wrote:
>      > On Mon, 5 May 2025 at 20:32, Petr Špaček <[e-mail]
>     <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>      >
>      >     On 5/5/25 14:49, Eric Vyncke (evyncke) wrote:
>      >      > Dear authors and WG,
>      >      >
>      >      > There have been substantive IETF Last Call comments once
>      >     extending the
>      >      > review outside of DNSOP. On my own read of the comments, there
>      >     are two
>      >      > critical ones:
>      >      >
>      >      >   * Are full-text explanations better or worse from UX or
>      >     security point
>      >      >     of view ?
>      >      >   * Should the draft merge/include/... with draft-
>     nottingham-public-
>      >      >     resolver-errors ?
>      >
>      >     Shameless plug: There is also a technical objection in
>      > https://mailarchive.ietf.org/arch/msg/last-call/ <https://
>     mailarchive.ietf.org/arch/msg/last-call/>
>      >     dsouS0lgD8UK36rWgqBkq8LKSWo/ <https://mailarchive.ietf.org/
>     arch/msg/ <https://mailarchive.ietf.org/arch/msg/>
>      >     last-call/dsouS0lgD8UK36rWgqBkq8LKSWo/>
>      >
>      >     under "Issue #1".
>      >
>      >     The current text breaks assumptions about EDE Option usage
>     defined in
>      >     RFC 8914 and does not state a good reason for it.
>      >
>      >
>      > This topic was discussed within the WG, and there was consensus
>     to reuse
>      > the EDE Option in the request as a signal of client interest in
>      > structured data, please see slide 4 in https://
>     datatracker.ietf.org/ <https://datatracker.ietf.org/>
>      > meeting/115/materials/slides-115-dnsop-structured-data-for-filtered-
>      > dns-01
> 
>     Could you please point me to the the decision, please?
> 
>     I did not find this being discussed on the mailing list. IETF 115 dnsop
>     minutes for this draft say only this:
>     -----
>     https://datatracker.ietf.org/doc/minutes-115-dnsop/ <https://
>     datatracker.ietf.org/doc/minutes-115-dnsop/>
> 
>     Structured Data for Filtered DNS
>           draft-wing-dnsop-structured-dns-error-page, Tirumal Reddy
>           Lots of industry interest
>           **Chairs Action: CfA**
>     -----
> 
>     To refresh my mind I went to IETF 115 dnsop recording here
>     https://meetecho-player.ietf.org/playout/?session=IETF115-
>     DNSOP-20221108-0930 <https://meetecho-player.ietf.org/playout/?
>     session=IETF115-DNSOP-20221108-0930>
>     and listened to block starting at 1:52:00. What I hear is call for
>     adoption a minute or two before the session ended and everyone went
>     home, not a technical discussion.
> 
>     Did I miss some other place where it was discussed? It's been a long
>     time so I might have missed something, obviously.
> 
> 
> It has been a long time, and I recall discussing this with resolver 
> providers who did not see any issues with implementing it. For instance, 
> it is already implemented byAdGuard’s DNS SDE extension <https:// 
> github.com/AdguardTeam/dns-sde-extension> and by Akamai (see DNS Errors 
> <https://datatracker.ietf.org/meeting/116/materials/slides-116-dnsop- 
> dns-errors-implementation-proposal-slides-116-dnsop-update-on-dns- 
> errors-implementation-00>).

Apparently we don't understand each other. I will try to explain 
differently.

Use of JSON in EDE EXTRA-TEXT in DNS _responses_ is okay as EXTRA-TEXT 
did not have defined content before.

What I consider to be a problem is sending empty EDE option in _DNS 
requests_ because the option is defined for use in _responses_.

I checked the AdGuard extension briefly and it does not seem to talk DNS 
at all. It uses HTTP API call to get the data - see here:
https://github.com/AdguardTeam/dns-sde-extension/blob/5d95e1b327675826703c8b0ae709bc5651849e77/src/index.js#L53C13-L53C66
so by definition it cannot send empty EDE option in DNS request, because 
there is no DNS request in the first place.


Second example in the slides (slide 9) show this command:
dig malw.scalone.eu +https @cns01-euce-4haj15.002.dev.4haj15.spscld.net

This 'dig' invocation does not send empty EDE option in request either.

In other words, there is prior art of sending JSON in EXTRA-TEXT answers 
- and that's perfectly okay!

I could not find prior art of even a technical discussion of sending 
empty EDE in _DNS requests_, which is what I'm objecting to.

Petr Špaček
Internet Systems Consortium

> 
>      > The same EDNS(0) option is
>      > permitted in both requests and responses, for example, RFC7828
>     (edns-
>      > tcp-keepalive) specifies the use of the option in both request/
>     response.
>      >
>      > It also maintains symmetry between signaling support for this
>     feature
>      > and delivering structured error information using the same option.
>     Just to be clear: I'm fine with using an option in both directions.
>     What
>     I object to is overloading meaning of an existing EDE option for
>     different purpose. Specifically EDE spec in RFC 8914 section 2 says:
> 
>       > The Extended DNS Error (EDE) option can be included in any response
>     (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that
>     includes an OPT pseudo-RR [RFC6891].
> 
>     It does not say anything about use in queries. I can't see a technical
>     reason for this overloading, and as resolver implementer I don't
>     want to
>     deal with complicated spec and resulting code if it can be made simpler.
> 
>     Hopefully I explained myself clearly now.