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

[tirumal reddy <[e-mail]>]

On Tue, 6 May 2025 at 14:20, Petr Špaček <[e-mail]> wrote:

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

Yes, thank you for the clarification. Is your concern that this usage
would break
existing resolver implementations that support RFC8914 but do not
implement this
draft ?

My understanding is that a resolver implementing only RFC8914 would ignore the
EDE option if it appears in a query, as RFC 8914 does not define EDE for use
in requests. It should not introduce any backward compatibility issues.
-Tiru