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

[tirumal reddy <[e-mail]>]

On Wed, 24 May 2023 at 19:30, Tommy Pauly <[e-mail]> wrote:

>
>
> On May 24, 2023, at 12:00 AM, tirumal reddy <[e-mail]> wrote:
>
> On Wed, 24 May 2023 at 01:48, Tommy Pauly <tpauly=
> [e-mail]> 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 include the hint and use the extra text if
>> it parses correctly.
>>
>
> Dependency on draft-ietf-add-resolver-info was added to address the threat
> where an attacker might inject (or modify) the EDE EXTRA-TEXT field with an
> DNS proxy or DNS forwarder that is unaware of EDE.More details are
> discussed in Section 10 of the draft.
>
>
> Using encrypted DNS to a known/trusted resolver can achieve this as well,
> so I think it is better as a recommendation of one way, but not a required
> way.
>

Works for me, we will update the draft.

-Tiru


>
> Tommy
>
>
> Cheers,
> -Tiru
>
>
>>
>> Tommy
>>
>> On May 23, 2023, at 9:52 AM, Dan Wing <[e-mail]> wrote:
>>
>> 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 better clarification in the document that
>> client has to check draft-ietf-add-resolver-info before including EDE OPT
>> in its DNS query. This check will further help interop by only sending EDE
>> in requests to servers that indicated support via
>> draft-ietf-add-resolver-info. However, it creates
>> draft-ietf-add-resolver-info as another hurdle to deployment of Structured
>> DNS error.  Thoughts?
>>
>> (I also put the above text into our github issues; I don't know which
>> folks prefer.
>> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/26
>> )
>>
>> -d
>>
>>
>> On May 22, 2023, at 7:44 PM, Tommy Pauly <tpauly=
>> [e-mail]> 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 length to 2 and the error to 0 (other error),
>> rather than a length of 0
>>
>> Both of these seem viable, and I’ll let the authors and WG decide which
>> is the right way forward.
>>
>> Best,
>> Tommy
>>
>> On May 22, 2023, at 5:00 PM, Mark Andrews <[e-mail]> wrote:
>>
>>
>>
>> On 23 May 2023, at 02:20, Tommy Pauly <tpauly=[e-mail]>
>> 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-ietf-dnsop-structured-dns-error-02.html#name-client-generating-request
>>
>> This is something that makes a lot of sense to me, and provides a great
>> way to indicate that a client would prefer to receive proper
>> blocked/filtered errors (with possible extra text) as opposed to a forged
>> answer.
>>
>> However, in testing this out, I’m seeing inconsistent compatibility with
>> some public resolvers. I was testing enabling this for encrypted resolvers
>> only, and I see the following behavior for a sampling of resolvers using
>> DoH:
>>
>> 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 like 8.8.8.8 or AdGuard)? Or is there a problem with the
>> approach this document is suggesting?
>>
>>
>> RFC 8914 left whether EDE in requests was permitted or not undefined.  I
>> can see an EDE implementation making the option parser return FORMERR if
>> the EDE option length was less than 2 and applying that to both requests
>> and responses.  RFC 8914 really should have said that EDE in requests
>> should be ignored and then there would have been a possibility on extending
>> behaviour based on adding EDE to a request.  We are already 10 years into
>> trying to fix unknown EDNS option behaviour and are still getting FORMERR
>> on unknown EDNS options in requests.  If the working group want to allow
>> extending EDE by adding it to a request is should obsolete RFC 8914 now
>> with RFC8914bis that specifies that EDE in requests are to be ignored.
>>
>> At the moment draft-ietf-dnsop-structured-dns-error-02 really should use
>> another EDNS option code point.  It really is not backwards compatible with
>> EDE the way it is currently specified.
>>
>>
>> Best,
>> Tommy
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone]              INTERNET: [e-mail]
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>