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

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

On 5/6/25 12:57, tirumal reddy wrote:
> 
> 
> On Tue, 6 May 2025 at 14:20, Petr Špaček <[e-mail] 
> <mailto:[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]>
>      > <mailto:[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]>>
>      >      > <mailto:[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/> <https://
>      > mailarchive.ietf.org/arch/msg/last-call/ <http://
>     mailarchive.ietf.org/arch/msg/last-call/>>
>      >      >     dsouS0lgD8UK36rWgqBkq8LKSWo/ <https://
>     mailarchive.ietf.org/ <https://mailarchive.ietf.org/>
>      >     arch/msg/ <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/ <http://datatracker.ietf.org/> <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/> <https://
>      > datatracker.ietf.org/doc/minutes-115-dnsop/ <http://
>     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-
>     <https://meetecho-player.ietf.org/playout/?session=IETF115->
>      >     DNSOP-20221108-0930 <https://meetecho-player.ietf.org/
>     playout/ <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 <http://github.com/
>     AdguardTeam/dns-sde-extension>> and by Akamai (see DNS Errors
>      > <https://datatracker.ietf.org/meeting/116/materials/slides-116-
>     dnsop- <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 <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 <http://malw.scalone.eu> +https @cns01-
>     euce-4haj15.002.dev.4haj15.spscld.net <http://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.
(Apologies for delay, real world scheduling got in my way.)

Yes, that's exactly the problem I'm trying to explain. The original EDE 
spec in RFC 8914 does not say what to do with EDE option in query at 
all. It describes behavior of the EDE option in answers, not requests.

EDNS spec RFC 6891 section 6.1.2 says:
    Any OPTION-CODE values not understood by a responder or requestor
    MUST be ignored.

But that's not applicable to the protocol as proposed by this draft. EDE 
OPTION-CODE is assigned, "understood", and has specific meaning, but the 
current draft proposes to do something undefined instead.

I can't see any technical reason why this option-meaning-overload is 
needed. Using a new OPTION-CODE would:
- be guaranteed to be compatible because RFC 6891 section 6.1.2 applies
- make it easier for tools like Wireshark etc. to disambiguate meaning
- save two bytes in the request

-- 
Petr Špaček
Internet Systems Consortium