Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

On Wed, 24 May 2023 at 19:30, Tommy Pauly wrote: > > > On May 24, 2023, at 12:00 AM, tirumal reddy wrote: > > On Wed, 24 May 2023 at 01:48, Tommy Pauly 40apple@dmarc.ietf.org> wrote: > >> Using length=2 and INFO-CODE=0 sounds fine to me. >> >> For the dependency on draft-ietf-add-resolver-i

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

> On May 24, 2023, at 12:00 AM, tirumal reddy wrote: > > On Wed, 24 May 2023 at 01:48, Tommy Pauly > wrote: >> Using length=2 and INFO-CODE=0 sounds fine to me. >> >> For the dependency on draft-ietf-add-resolver-info, I don't think we need to >> impose tha

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

On Wed, 24 May 2023 at 01:48, Tommy Pauly wrote: > Using length=2 and INFO-CODE=0 sounds fine to me. > > For the dependency on draft-ietf-add-resolver-info, I don't think we need > to impose that dependency. I'd much prefer to allow clients to look at that > optionally, but still be able to inclu

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Moin! On 23 May 2023, at 22:18, Tommy Pauly wrote: > Using length=2 and INFO-CODE=0 sounds fine to me. > > For the dependency on draft-ietf-add-resolver-info, I don't think we need to > impose that dependency. I'd much prefer to allow clients to look at that > optionally, but still be able to i

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Using length=2 and INFO-CODE=0 sounds fine to me. For the dependency on draft-ietf-add-resolver-info, I don't think we need to impose that dependency. I'd much prefer to allow clients to look at that optionally, but still be able to include the hint and use the extra text if it parses correctly

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

EDE length=2 with INFO-CODE=0 works nicely. Also because non-EDE-aware DNS responders can be vulnerable to attacks described in Security Considerations, the Security Considerations section currently suggests clients use draft-ietf-add-resolver-info to check if server supports EDE. This needs be

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

To clarify, the point of the signal in the request is to indicate that the client knows how to handle EDE responses of filtered/blocked/etc. When a resolver is filtering, it has to deal with both legacy clients and EDE-aware clients: - For legacy clients, it will send a forged answer that sends

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Moin! On 23 May 2023, at 9:45, Mark Andrews wrote: >> I agree. Sending empty EDE in requests seems superfluous to me. > > The point of adding it to the request is to signal that that client will do > the filtering. No, the filtering is done by the server giving back NXDomain or something other

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

> On 23 May 2023, at 17:11, Petr Špaček wrote: > > On 23. 05. 23 7:03, Ralf Weber wrote: >> Moin! >> On 23 May 2023, at 4:44, Tommy Pauly wrote: >>> Thanks, Mark. >>> >>> For what it's worth, I just ran two other tests, and for both of these >>> cases, all of the resolvers I tried did accept

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

On 23. 05. 23 7:03, Ralf Weber wrote: Moin! On 23 May 2023, at 4:44, Tommy Pauly wrote: Thanks, Mark. For what it's worth, I just ran two other tests, and for both of these cases, all of the resolvers I tried did accept the request: - Choose a new EDNS option code point (I just tested 50, ra

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Moin! On 23 May 2023, at 4:44, Tommy Pauly wrote: > Thanks, Mark. > > For what it's worth, I just ran two other tests, and for both of these cases, > all of the resolvers I tried did accept the request: > - Choose a new EDNS option code point (I just tested 50, randomly) > - Use EDE but set the

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Thanks, Mark. For what it's worth, I just ran two other tests, and for both of these cases, all of the resolvers I tried did accept the request: - Choose a new EDNS option code point (I just tested 50, randomly) - Use EDE but set the length to 2 and the error to 0 (other error), rather than a le

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

> On 23 May 2023, at 02:20, Tommy Pauly > wrote: > > Hello DNSOP, > > In draft-ietf-dnsop-structured-dns-error, there’s a description of how > clients should indicate that they understand extended DNS errors (EDE) by > sending an empty EDE option. > > https://www.ietf.org/archive/id/draft

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Moin! On 22 May 2023, at 18:20, Tommy Pauly wrote: > 1.1.1.1 - NOERROR, works fine! > 9.9.9.9 - NOERROR, works fine! > 8.8.8.8 - FORMERR on all responses > dns.adguard-dns.com - SERVFAIL on all responses > > Do we think that this should be allowed in queries (and thus this is a bug in > resolvers

[DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Hello DNSOP, In draft-ietf-dnsop-structured-dns-error, there’s a description of how clients should indicate that they understand extended DNS errors (EDE) by sending an empty EDE option. https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.html#name-client-generating-reques