[DNSOP] dnsop - Update to a Meeting Session Request for IETF 117

[IETF Meeting Session Request Tool]

An update to a meeting session request has just been submitted by Tim
Wicinski, a Chair of the DNSOP Working Group.


-
Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski


Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 160
Conflicts to Avoid: 
 Chair conflict: dance add dprive dkim dbound2
 Technology overlap: quic dinrg lamps maprg 6man dhc regext intarea dnssd dmarc

   


Participants who must be present:

Resources Requested:

Special Requests:
  
-


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Domain Verification Techniques using DNS

[elliott . brown=40num . uk]

Thank you for your reply Shivan,

Your comment cleared some things up for me:

> The draft surveyed several widely deployed techniques and synthesized best 
> current practices. The technique you're proposing is a new technique, and 
> worth considering in its own separate document by the DNSOP working group.

It's now clear that our technique is not widely deployed and so I understand 
that it might not be relevant for a Best Current Practice document. I think 
this could be a lack of understanding on my part about how BCP documents work 
and so I'll do some reading on that.

Thanks for your help,

Elliott

--- Original Message ---
On Wednesday, May 24th, 2023 at 23:03, Shivan Kaul Sahib 
 wrote:

> Hi Elliott,
>
> On Wed, 24 May 2023 at 14:52,  wrote:
>
>> --- Original Message ---
>> On Tuesday, May 23rd, 2023 at 21:22, Paul Wouters 
>>  wrote:
>>
>>> On Mon, May 22, 2023 at 5:49 PM  wrote:
>>>
 Dear DNSOP WG,

 My company has developed a domain verification technique using DNS, it 
 fits the abstract of draft-ietf-dnsop-domain-verification-techniques.

 I am writing to ask the WG's opinion on whether our technique is within 
 the scope of the current draft and if so, whether it should be considered 
 for inclusion.
>>>
>>> Thanks for reaching out to DNSOP.
>>>
 Our technique is outlined here:
 https://www.domainverification.org

 You can see an example DNS TXT record by using the following dig command:

 dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com 
 TXT

 Although our method fits the draft's title and abstract, it is quite 
 different to the method detailed in the best current practice of the draft.
>>>
>>> Indeed. While the current draft's methods could be fully automated, your 
>>> method specifically calls out for verification via
>>> a phone number or email address which more or less assumes a human operator.
>>
>> The current draft's methods (Service Provider: instructing a domain owner to 
>> create a DNS TXT record; Domain Owner: creating the DNS TXT record) are 
>> automated on the service provider side, but in my experience it is very 
>> rarely automated on the domain owner side.
>>
>> On the domain owner side, there is a human operator following the 
>> instructions and creating the DNS TXT record.
>>
>> Our method does involve an extra step of verification (e.g. verifying an 
>> email address), but in practice this extra step has often already been 
>> completed when the domain owner set up a user account with the service 
>> provider.
>>
>>> It therefor works indirectly and all the
>>> "verification" parts are out of scope handled inside the SMS / email / 
>>> phone call messages that would be required.
>>>
>>> As such, I do not think it belings in the current draft, but should be 
>>> submitted as a separate draft.
>>
>> I am very open to submitting it as a separate draft and I am interested in 
>> the thoughts of the WG around whether the abstract of the current draft (and 
>> possibly title) should be narrowed to make it clear the domain verification 
>> techniques included in the current draft are for one-time only / service 
>> provider specific domain verification.
>
> I agree with Paul that this seems like a separate draft that should be 
> considered on its own by the WG.
>
 It is our ultimate goal for these records to be created by domain 
 registrars upon domain registration (with registrant opt-in) to provide 
 their customers with seamless onboarding when adding their domain to 
 service providers.
>>>
>>> I wonder if that goal is achievable. In a way, the SOA record also contains 
>>> a contact email for the domain and is basically no longer used by anyone.
>>
>> The zonemaster is not the domain owner in the vast majority of cases. I 
>> think there's a variety of reasons this email address is no longer used by 
>> anyone, including: it is in plaintext so easily discoverable; there are 
>> better ways to contact the administrator of a DNS zone.
>>
>>> Hashing the contact info is only a very wea protection, as we have seen 
>>> with people bruteforcing NSEC3 hash chains.
>>
>> We hash the email/phone and store it in the DNS label itself so that it 
>> cannot be easily harvested by spammers. We don't use hashing for any kind of 
>> protection against a threat.
>>
>>> And also, I think
>>> these type of records will also go stale and then not very useful.
>>
>> These records will naturally be removed when a domain expires or changes 
>> registrant, so I think the risk of stale records for a domain owner is quite 
>> low. Records for third parties can have expiry dates, so I think this should 
>> avoid stale records for third parties.
>>
>>> And so another fallback mechanism will be required anyway. So perhaps using 
>>> that fallback to start with would be better. (I guess you could add some 
>>> application code to verify email addresses on signup 

Re: [DNSOP] Domain Verification Techniques using DNS

[Shivan Kaul Sahib]

Hi Elliott,

On Wed, 24 May 2023 at 14:52,  wrote:

> --- Original Message ---
> On Tuesday, May 23rd, 2023 at 21:22, Paul Wouters  40aiven...@dmarc.ietf.org> wrote:
>
>
> On Mon, May 22, 2023 at 5:49 PM  wrote:
>
>> Dear DNSOP WG,
>>
>> My company has developed a domain verification technique using DNS, it
>> fits the abstract of draft-ietf-dnsop-domain-verification-techniques.
>>
>> I am writing to ask the WG's opinion on whether our technique is within
>> the scope of the current draft and if so, whether it should be considered
>> for inclusion.
>>
>
> Thanks for reaching out to DNSOP.
>
>
>> Our technique is outlined here:
>> https://www.domainverification.org
>>
>> You can see an example DNS TXT record by using the following dig command:
>>
>> dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com
>> TXT
>>
>> Although our method fits the draft's title and abstract, it is quite
>> different to the method detailed in the best current practice of the draft.
>>
>
> Indeed. While the current draft's methods could be fully automated, your
> method specifically calls out for verification via
> a phone number or email address which more or less assumes a human
> operator.
>
>
> The current draft's methods (Service Provider: instructing a domain owner
> to create a DNS TXT record; Domain Owner: creating the DNS TXT record) are
> automated on the service provider side, but in my experience it is very
> rarely automated on the domain owner side.
>
> On the domain owner side, there is a human operator following the
> instructions and creating the DNS TXT record.
>
> Our method does involve an extra step of verification (e.g. verifying an
> email address), but in practice this extra step has often already been
> completed when the domain owner set up a user account with the service
> provider.
>
> It therefor works indirectly and all the
> "verification" parts are out of scope handled inside the SMS / email /
> phone call messages that would be required.
>
> As such, I do not think it belings in the current draft, but should be
> submitted as a separate draft.
>
>
> I am very open to submitting it as a separate draft and I am interested in
> the thoughts of the WG around whether the abstract of the current draft
> (and possibly title) should be narrowed to make it clear the domain
> verification techniques included in the current draft are for one-time only
> / service provider specific domain verification.
>


I agree with Paul that this seems like a separate draft that should be
considered on its own by the WG.


>
> It is our ultimate goal for these records to be created by domain
>> registrars upon domain registration (with registrant opt-in) to provide
>> their customers with seamless onboarding when adding their domain to
>> service providers.
>>
>
> I wonder if that goal is achievable. In a way, the SOA record also
> contains a contact email for the domain and is basically no longer used by
> anyone.
>
>
> The zonemaster is not the domain owner in the vast majority of cases. I
> think there's a variety of reasons this email address is no longer used by
> anyone, including: it is in plaintext so easily discoverable; there are
> better ways to contact the administrator of a DNS zone.
>
> Hashing the contact info is only a very wea protection, as we have seen
> with people bruteforcing NSEC3 hash chains.
>
>
> We hash the email/phone and store it in the DNS label itself so that it
> cannot be easily harvested by spammers. We don't use hashing for any kind
> of protection against a threat.
>
> And also, I think
> these type of records will also go stale and then not very useful.
>
>
> These records will naturally be removed when a domain expires or changes
> registrant, so I think the risk of stale records for a domain owner is
> quite low. Records for third parties can have expiry dates, so I think this
> should avoid stale records for third parties.
>
> And so another fallback mechanism will be required anyway. So perhaps
> using that fallback to start with would be better. (I guess you could add
> some application code to verify email addresses on signup requests, but I
> doubt this is all going to me that much easier than "take this DNS record
> and tell your IT to publish it for a few days" that the current draft uses.
>
>
> I would argue that the service providers that verify the most domains
> already verify email addresses on sign-up. And so, once the Domain
> Verification Protocol record is in place – whether it's been setup by the
> domain registrant, registrar or a previous service provider – domain
> verification becomes "automatic" and significantly easier than "take this
> DNS record and tell your IT to publish it for a few days".
>
> I have provided an explanation of the process below:
>
> 1. Bob signs up with DomainRegistrar.com using email b...@gmail.com and
> registers the available domain example.com
>
> 2. DomainRegistrar.com configures a Domain Verification 

Re: [DNSOP] Domain Verification Techniques using DNS

[elliott . brown=40num . uk]

--- Original Message ---
On Tuesday, May 23rd, 2023 at 21:22, Paul Wouters 
 wrote:

> On Mon, May 22, 2023 at 5:49 PM  wrote:
>
>> Dear DNSOP WG,
>>
>> My company has developed a domain verification technique using DNS, it fits 
>> the abstract of draft-ietf-dnsop-domain-verification-techniques.
>>
>> I am writing to ask the WG's opinion on whether our technique is within the 
>> scope of the current draft and if so, whether it should be considered for 
>> inclusion.
>
> Thanks for reaching out to DNSOP.
>
>> Our technique is outlined here:
>> https://www.domainverification.org
>>
>> You can see an example DNS TXT record by using the following dig command:
>>
>> dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com TXT
>>
>> Although our method fits the draft's title and abstract, it is quite 
>> different to the method detailed in the best current practice of the draft.
>
> Indeed. While the current draft's methods could be fully automated, your 
> method specifically calls out for verification via
> a phone number or email address which more or less assumes a human operator.

The current draft's methods (Service Provider: instructing a domain owner to 
create a DNS TXT record; Domain Owner: creating the DNS TXT record) are 
automated on the service provider side, but in my experience it is very rarely 
automated on the domain owner side.

On the domain owner side, there is a human operator following the instructions 
and creating the DNS TXT record.

Our method does involve an extra step of verification (e.g. verifying an email 
address), but in practice this extra step has often already been completed when 
the domain owner set up a user account with the service provider.

> It therefor works indirectly and all the
> "verification" parts are out of scope handled inside the SMS / email / phone 
> call messages that would be required.
>
> As such, I do not think it belings in the current draft, but should be 
> submitted as a separate draft.

I am very open to submitting it as a separate draft and I am interested in the 
thoughts of the WG around whether the abstract of the current draft (and 
possibly title) should be narrowed to make it clear the domain verification 
techniques included in the current draft are for one-time only / service 
provider specific domain verification.

>> It is our ultimate goal for these records to be created by domain registrars 
>> upon domain registration (with registrant opt-in) to provide their customers 
>> with seamless onboarding when adding their domain to service providers.
>
> I wonder if that goal is achievable. In a way, the SOA record also contains a 
> contact email for the domain and is basically no longer used by anyone.

The zonemaster is not the domain owner in the vast majority of cases. I think 
there's a variety of reasons this email address is no longer used by anyone, 
including: it is in plaintext so easily discoverable; there are better ways to 
contact the administrator of a DNS zone.

> Hashing the contact info is only a very wea protection, as we have seen with 
> people bruteforcing NSEC3 hash chains.

We hash the email/phone and store it in the DNS label itself so that it cannot 
be easily harvested by spammers. We don't use hashing for any kind of 
protection against a threat.

> And also, I think
> these type of records will also go stale and then not very useful.

These records will naturally be removed when a domain expires or changes 
registrant, so I think the risk of stale records for a domain owner is quite 
low. Records for third parties can have expiry dates, so I think this should 
avoid stale records for third parties.

> And so another fallback mechanism will be required anyway. So perhaps using 
> that fallback to start with would be better. (I guess you could add some 
> application code to verify email addresses on signup requests, but I doubt 
> this is all going to me that much easier than "take this DNS record and tell 
> your IT to publish it for a few days" that the current draft uses.

I would argue that the service providers that verify the most domains already 
verify email addresses on sign-up. And so, once the Domain Verification 
Protocol record is in place – whether it's been setup by the domain registrant, 
registrar or a previous service provider – domain verification becomes 
"automatic" and significantly easier than "take this DNS record and tell your 
IT to publish it for a few days".

I have provided an explanation of the process below:

1. Bob signs up with DomainRegistrar.com using emailbob@gmail.comand registers 
the available domain[example.com](http://example.com/)

2. DomainRegistrar.com configures a Domain Verification record by 
hashing...@gmail.com(simplified hash: 123ABC) and stores this record at 
123ABC._[dv.example.com](http://dv.example.com/)

3. Bob signs up with Service Provider 1 using his emailbob@gmail.comand 
verifies his email. He attempts to add the 

Re: [DNSOP] [Ext] Call for Adoption: draft-klh-dnsop-rfc8109bis

[Paul Hoffman]

On May 24, 2023, at 7:01 AM, Tim Wicinski  wrote:
> 
> 
> All
> 
> The authors for RFC8109 have made some updates to their document
> "Initializing a DNS Resolver with Priming Queries", and are looking to have 
> the
> work adopted by DNSOP. 
> 
> You can see the changes made since RFC8109 here:
> 
> https://author-tools.ietf.org/iddiff?url1=rfc8109=draft-klh-dnsop-rfc8109bis-06=--html
> 
> This starts a Call for Adoption for draft-klh-dnsop-rfc8109bis
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-klh-dnsop-rfc8109bis/
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 7 June 2023

As a note on the timeliness of this, the root zone KSK will be changed in about 
two years. These events often cause the community to ask questions about 
priming, not just about DNSSEC. It would be grand (but not required) if we 
could have this update as a new RFC before the new KSK is relied on in the root 
zone.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP WG Interim June 2023 planning: draft-ietf-dnsop rfc8499bis and lame delegation

[Benno Overeinder]

Dear WG,

As mentioned earlier on the mailing list, the chairs are planning an 
interim meeting in June to discuss the three options on how to proceed 
with draft-ietf-dnsop-rfc8499bis wrt. lame delegation:


1) Stick with the current text in the document – the original definition 
from RFC8499 plus a note that "These early definitions do not match the 
current use of the term "lame delegation", but there is no consensus on 
what a lame delegation is."
A possible follow-up to this is for someone to start a WG consensus 
document on "lame", which can update 8499bis.
2) We still find a rough consensus on the definition proposed in the 
"Meaning of lame delegation" email thread, and the WG can agree that 
this is a definition useful to DNS engineers/operators.
3) Withdraw the document from WGLC so we can add definitions.  Do not 
propose any new terms and definitions at this stage if we choose this 
option.



Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/az7Z5AOb

The options for the time slots are a compromise for CEST/EDT/PDT/AEST/JST.

We will close the Doodle poll at the end of Tuesday 30 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis

[Tim Wicinski]

All

The authors for RFC8109 have made some updates to their document
"Initializing a DNS Resolver with Priming Queries", and are looking to have
the
work adopted by DNSOP.

You can see the changes made since RFC8109 here:

https://author-tools.ietf.org/iddiff?url1=rfc8109=draft-klh-dnsop-rfc8109bis-06=--html

This starts a Call for Adoption for draft-klh-dnsop-rfc8109bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-klh-dnsop-rfc8109bis/


Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 7 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSOP WG has placed draft-klh-dnsop-rfc8109bis in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The DNSOP WG has placed draft-klh-dnsop-rfc8109bis in state
Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-klh-dnsop-rfc8109bis/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

> 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 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.

Tommy
> 
> Cheers,
> -Tiru
>  
>> 
>> Tommy
>> 
>>> On May 23, 2023, at 9:52 AM, Dan Wing >> > 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 
 mailto:40apple@dmarc.ietf.org>> 
 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  > wrote:
> 
> 
> 
>> 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-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 

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

[tirumal reddy]

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 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.

Cheers,
-Tiru


>
> Tommy
>
> On May 23, 2023, at 9:52 AM, Dan Wing  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  40apple@dmarc.ietf.org> 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  wrote:
>
>
>
> 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-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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
>