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

[tirumal reddy <[e-mail]>]

On Mon, 5 May 2025 at 21:23, Petr Špaček <[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]>> 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/
> >     dsouS0lgD8UK36rWgqBkq8LKSWo/ <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/
> > 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/
>
> 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
> 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 by AdGuard’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>
).

-Tiru


>
>
> > 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.
>
> --
> Petr Špaček
> Internet Systems Consortium
>