On Tue, 6 May 2025 at 14:20, Petr Špaček <[email protected]> wrote: > On 5/6/25 10:28, tirumal reddy wrote: > > On Mon, 5 May 2025 at 21:23, Petr Špaček <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 5/5/25 17:27, tirumal reddy wrote: > > > On Mon, 5 May 2025 at 20:32, Petr Špaček <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> 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
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
