On 5/6/25 10:28, tirumal reddy wrote:
On Mon, 5 May 2025 at 21:23, Petr Špaček <pspa...@isc.org
<mailto:pspa...@isc.org>> wrote:
On 5/5/25 17:27, tirumal reddy wrote:
> On Mon, 5 May 2025 at 20:32, Petr Špaček <pspa...@isc.org
<mailto:pspa...@isc.org>
> <mailto:pspa...@isc.org <mailto:pspa...@isc.org>>> 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.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
