On 5/6/25 12:57, tirumal reddy wrote:
On Tue, 6 May 2025 at 14:20, Petr Špaček <pspa...@isc.org
<mailto:pspa...@isc.org>> wrote:
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>
> <mailto: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>>
> > <mailto: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/> <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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
