Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Tommy Pauly]

> On Oct 19, 2023, at 12:44 PM, Warren Kumari  wrote:
> 
> I still don't understand why (other than marketing/advertising) this is 
> needed — the EDE "4.18. Extended DNS Error Code 17 - Filtered" ("The server 
> is unable to respond to the request because the domain is on a blocklist as 
> requested by the client. Functionally, this amounts to "you requested that we 
> filter domains like this one.") seems to cover it.
> 
> If browsers are willing to do anything with the EDE codes (like "ERROR: Your 
> DNS filtering provider says you shouldn't go here") what additional 
> **important** information needs to be communicated? And if browsers are not 
> willing to do anything with just EDE codes, it sure doesn't seem like they 
> would want to do that **and** follow an unauthenticated URL… 

Safari is now displaying the EDE-code based information! So we are willing to 
show that.

The case that might still be interesting is providing the user some (hopefully 
safe) way to contact the blocker to dispute why this is being blocked — so a 
way to send an email to an administrator, but not something else. Showing 
advertising or marketing or any arbitrary page is not something I think would 
fly.

Tommy
> 
> Anything more simply adds complexity and security risks, and entails privacy 
> concerns for the user too…
> 
> W
> 
> 
> On Thu, Oct 19, 2023 at 4:05 AM, Vodafone Gianpaolo Angelo Scalone 
>  > wrote:
>> Hi,
>> 
>> I think that we have now 2 good potential compromises:
>> 
>> A browser interstitial page explaining that the following page is generated 
>> by the service that blocked the actual page, with a button indicating 
>> “proceed to the blocking page” and another “dismiss”
>> A graphical representation of the blocking page, rendered as image with no 
>> clickable links, with a button indicating “proceed to the blocking page” and 
>> another “dismiss”
>>  
>> This would be understandable by customers and provide a good user experience 
>> and security.
>> 
>> In addition we could start thinking about a reputation mechanism.
>> 
>>  
>> Kind regards
>> 
>>  
>> Gianpaolo
>> 
>> 
>> C2 General
>> ___ 
>> 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
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Tommy Pauly]

> On Oct 11, 2023, at 3:17 PM, Warren Kumari  wrote:
> 
> 
> 
> 
> 
> On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone 
>  > wrote:
>> I really love this draft and would like to see browser side implementation 
>> for the benefit of customers user experience. Today several services are 
>> implemented on top of DNS to filter malicious or unwanted traffic in an 
>> effective way, but customers cannot distinguish the blocking from a network 
>> error. This led to frustration or even worst put them in danger: a quick 
>> solution to the "network error" is to disable the protection and so be 
>> infected, or change browser. The server side implementation provides all the 
>> needed information to build a great user experience: in the example below I 
>> see at least 2 options
>> 
>> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987 flags: qr rd ra; 
>> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS: 
>> version: 0, flags:; udp: 512
>> EDE: 17 (Filtered): ({ "c": 
>> [https://blocking.vodafone.com/blockpage?list=malwarecc], "s": 1,"j": 
>> "Malware C", "o": "Vodafone Internet Services" }) QUESTION SECTION: 
>> malw.scalone.eu . IN A
>> 
>> Option 1 - better user experience, some complexity to avoid security risks
>> 
>> if the contact URI is trusted it is possible to present in the GUI a real 
>> blocking page. The problem is that untrusted providers could use this method 
>> as an attack vector. Potential solutions could be:
>> Browsers accept Exte4nded DNS Errors only from DoH servers. URI domain has 
>> to be covered by DoH server certificate. There could potentially be a 
>> vetting process e.g. through IANA, whereby filtering providers would need to 
>> register. Only registered and approved providers would then be permitted to 
>> use this method
>> 
>> Option 2 - Sub-optimal user experience; however, a significant improvement 
>> over today's user experience. 
>> 
>>  cannot open  because it has 
>> been filtered by  
>> Blocking reason: 
>> 
>> 
>> 
> 
> 
> Erm, can't a large amount of this already be accomplished using RFC8914 
> Extended Errors. E.g:
> https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-15-
> —-
> "4.16. Extended DNS Error Code 15 - Blocked
> The server is unable to respond to the request because the domain is on a 
> blocklist due to an internal security policy imposed by the operator of the 
> server resolving or forwarding the query.
> 
> 4.17. Extended DNS Error Code 16 - Censored
> The server is unable to respond to the request because the domain is on a 
> blocklist due to an external requirement imposed by an entity other than the 
> operator of the server resolving or forwarding the query. Note that how the 
> imposed policy is applied is irrelevant (in-band DNS filtering, court order, 
> etc.).
> 
> 4.18. Extended DNS Error Code 17 - Filtered
> The server is unable to respond to the request because the domain is on a 
> blocklist as requested by the client. Functionally, this amounts to "you 
> requested that we filter domains like this one."
> --- 
> 
> Yes, it doesn't give you the HTML page, but I personally view that as a 
> feature, not a bug.
> You *know* that if my coffee-shop/hotel/car-dealer has the ability to respond 
> to every N-th DNS query with:
> "({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({ "c": 
> [https://www.example.com/free-donut-with-every-pumpkin-spice-latte.]})"
> they will.
> 
> Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers, but 
> with captive-portals and similar many people do…

Yeah, the existing error codes are quite good (and iOS and macOS natively 
support them now!), but having more details would allow this to replace more 
fully the cases where redirection occurs.

I also am concerned about someone just putting advertisements or worse in the 
contact information, so there should be some control on it.

Tommy

> 
> W
> 
> 
> 
>> Thank you
>> 
>> Gianpaolo
>> 
>> C2 General
>> 
>> ___
>> 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
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Tommy Pauly]

As another enthusiastic follower of this document, I appreciate the suggestions 
from Gianpaolo here.

Looking at the document, in section 5.3, it does cover some of the suggestions, 
particularly that the extra-text MUST be over encrypted DNS, and MUST NOT be 
opportunistic.

Having a requirement that the contact needs to be related to / covered by the 
resolver cert is interesting. I’d be curious to hear if this would generally 
work for resolvers?

Thanks,
Tommy


> On Oct 10, 2023, at 9:56 AM, Gianpaolo Angelo Scalone, Vodafone 
>  wrote:
> 
> 
> I really love this draft and would like to see browser side implementation 
> for the benefit of customers user experience.
> Today several services are implemented on top of DNS to filter malicious or 
> unwanted traffic in an effective way, but customers cannot distinguish the 
> blocking from a network error. 
> This led to frustration or even worst put them in danger: a quick solution to 
> the "network error" is to disable the protection and so be infected, or 
> change browser.
> The server side implementation provides all the needed information to build a 
> great user experience: in the example below I see at least 2 options
> 
> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987
> flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT 
> PSEUDOSECTION:
> EDNS: version: 0, flags:; udp: 512
> EDE: 17 (Filtered): ({ "c": 
> [https://blocking.vodafone.com/blockpage?list=malwarecc], "s": 1,"j": 
> "Malware C", "o": "Vodafone Internet Services" }) QUESTION SECTION:
> malw.scalone.eu.  IN  A
> 
> Option 1 - better user experience, some complexity to avoid security risks
> 
> if the contact URI is trusted it is possible to present in the GUI a real 
> blocking page. 
> The problem is that untrusted providers could use this method as an attack 
> vector.
> Potential solutions could be:
> Browsers accept Exte4nded DNS Errors only from DoH servers.
> URI domain has to be covered by DoH server certificate.
> There could potentially be a vetting process e.g. through IANA, whereby 
> filtering providers would need to register. Only registered and approved 
> providers would then be permitted to use this method
> 
> Option 2 - Sub-optimal user experience; however, a significant improvement 
> over today's user experience. 
> 
>  cannot open  because it has 
> been filtered by  
> Blocking reason: 
> 
> Thank you
> 
> Gianpaolo
> 
> C2 General
> 
> ___
> 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

Re: [DNSOP] Questions on DNS HTTPS/SVCB spec and deployment

[Tommy Pauly]

> 
> I don't know much about the state of client implementations.


Regarding client implementations, for the one we use on iOS/macOS/etc, we built 
this into our happy eyeballs algorithm — so as we receive addresses from the 
hints in SVCB, and A, and , we add them to our list that we are racing 
various attempts based on. If we get the hints first, we’ll start trying with 
those, but will add in the other answers as they come and use them if needed.

Thanks,
Tommy

> --Ben Schwartz
> From: DNSOP mailto:dnsop-boun...@ietf.org>> on 
> behalf of Hongying Dong  >
> Sent: Monday, July 24, 2023 1:13 PM
> To: dnsop@ietf.org   >
> Subject: [DNSOP] Questions on DNS HTTPS/SVCB spec and deployment
>  
> Hello,
> We are researchers at the University of Virginia studying some aspects of the 
> DNS HTTPS/SVCB specification and how it is deployed in practice. We had a few 
> questions we are hoping you can provide the answers to. Primarily we are 
> examining HTTPS right now, but if the answers can be generally provided for 
> SVCB too, that would be great.
> * IPv4 and IPv6 hints.
> The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use 
> to reach the service.  If A and  records for TargetName are locally 
> available, the client SHOULD ignore these hints. Otherwise, clients SHOULD 
> perform A and/or  queries for TargetName as in Section 3, and clients 
> SHOULD use the IP address in those responses for future connections.  Clients 
> MAY opt to terminate any connections using the addresses in hints and instead 
> switch to the addresses in response to the TargetName query.  Failure to use 
> A and/or  response addresses could negatively impact load balancing or 
> other geo-aware features and thereby degrade client performance.
> It seems to us that unless the IPv4 and IPv6 hints are kept diligently in 
> sync with the actual addresses in the A and  records, this could easily 
> pose operational problems in the field. The draft appears to concur and says 
> clients should see if they are "locally available", and otherwise "SHOULD" 
> perform A/ address lookups. If so, under what circumstances is it 
> beneficial for an implementation to follow the "MAY" instruction of the first 
> line in the above quoted paragraph and use the hints?
> Also what does "If the A and  records for Targetname are _locally 
> available_" mean? Is the expectation that HTTPS client applications run a 
> local DNS cache from which this information could be extracted?
> The  answer to the "MAY use hints" is suggested later on in this paragraph:
> These parameters are intended to minimize additional connection latency when 
> a recursive resolver is not compliant with the requirements in Section 4, and 
> SHOULD NOT be included if most clients are using compliant recursive 
> resolvers.
> First, how would a client application generally know that a recursive server 
> is compliant with Section 4 (i.e. proactively fetching the A and  records 
> for the HTTPS Targetname and providing them in the response)? Is there a 
> proposed DNS API function that provides this information, or are clients 
> expected to write custom code to parse the full response from a recursive 
> server to figure this out? Second, how would a service operator publishing 
> HTTPS records know if most of their clients are using compliant recursive 
> servers to help them make a decision about including IP hints? Or does this 
> statement imply that everyone should deploy IP hints until the ecosystem has 
> gained a critical mass of recursive servers that are compliant?
> What recursive servers today support this optimization? We've examined 
> several of the public DNS resolvers (Google, Cloudflare, Quad9, and OpenDNS) 
> and none of them appear to. We haven't looked at the open source 
> implementations yet, but if anyone can answer that would be appreciated too.
> Client implementation behavior in the field: What do existing web 
> browsers/clients (e.g. Firefox, Chrome, Safari, etc) that support DNS HTTPS 
> records do today? Under what conditions do they use the hints vs. query 
> explicitly for address records?
> 
> Thank you so much!
> Hongying
> 
> -- 
> Hongying Dong
> Ph.D. Candidate in Computer Engineering
> University of Virginia
> ___
> 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

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  <mailto:40apple@dmarc.ietf.org>> 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 >> <mailto:danw...@gmail.com>> 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 >>>> <mailto:ma...@isc.org>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 23 May 2023, at 02:20, Tommy Pauly >>>>> <mailto:40apple@dmarc.ietf.org>> 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 <http://dns.adguard-dns.com/> - SERVFAIL on all 
>>>>>> responses
>>>>>> 
>&

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

[Tommy Pauly]

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.

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  
>> 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
>>>> ___
>>&

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

[Tommy Pauly]

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 a browser, etc, 
to a page that explains that they’re blocked. This technique is very 
problematic (breaks TLS cert trust, etc), but is very common, and unfortunately 
many resolvers won’t be willing to stop doing this for legacy clients.
- For clients that understand EDE for filtered/blocked etc, particularly if 
extra-text can be used, the resolver would instead prefer to use that 
mechanism. However, these EDE codes can’t be used with a forged answer, so the 
resolver needs to know the client understands how to deal with the errors in a 
sensible way.

Just using the OPT pseudo-RR isn’t enough — clients will include padding for 
DoH, etc, but still not know how to deal with EDE. So an explicit signal is 
preferable here.

Tommy

> On May 23, 2023, at 12:45 AM, Mark Andrews  wrote:
> 
> 
> 
>> 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 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
>>> I don’t think we need a new code point. Just having a valid opt record 
>>> without a further option will work as RFC8914 states:
>>> 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]. This document includes a set of initial 
>>> codepoints but is extensible via the IANA registry defined and created in 
>>> Section 5.2.
>>> and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines 
>>> a special format for the EDE EXTRA-TEXT field the most backward compatible 
>>> solution IMHO is just to rely on the mechanism defined in RFC8914, and not 
>>> to define any special handling.
>>> So I would propose 5.1 to be:
>>> When generating a DNS query, the client includes the OPT pseudo-RR 
>>> [RFC6891] to elicit the Extended DNS Error option in the DNS response.
>> 
>> 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.
> 
> Even if signalling is removed the current text is incompatible with EDE.  
> Read it in “perverse” mode (client will be stupid).
> 
>> -- 
>> Petr Špaček
>> Internet Systems Consortium
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto: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 
> <mailto:ma...@isc.org>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop

___
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]

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 <mailto: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 
> <mailto:ma...@isc.org>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

[Tommy Pauly]

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?

Best,
Tommy___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Additional Working Group Last Call for draft-ietf-dnsop-svcb-http

[Tommy Pauly]

Thanks to the authors for making the change, and for the chairs for running 
this additional WGLC!

The changes look good to me.

Best,
Tommy

> On Mar 11, 2023, at 12:44 PM, Tim Wicinski  wrote:
> 
> 
> All
> 
> The SVCB document has been returned from the RFC Editor, and we thank Warren 
> for doing all the crazy process stuff to make this happen.  The authors have 
> made the changes - removing the references to ECH (and I thank them for doing 
> this quickly and efficiently).   They are creating a separate document 
> describing the ech flags for SVCB, with the plan to submit into the TLS 
> working group.
> 
> Here is the Diff from the previous version
> 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-svcb-https-12
> 
> (it shows a much greater set of changes than what really changed). 
> 
> Because of this, we're starting a week Working Group Last Call on 
> draft-ietf-dnsop-svcb-https, to have the WG confirm the changes removing the 
> references has not caused other issues.
> 
> What is not on the table to discuss during the WGLC are other changes to the 
> document.  This is from Warren, so if there are issues with that, please 
> include him in any discussions.
> 
> This WGLC will end on March 18th 2023
> 
> tim
> 
> ___
> 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

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

[Tommy Pauly]

I support this plan, and am eager to see the logjam unblocked!

The mechanism for how we reintroduce the ECH option for SVCB can be debated 
separately. I like the idea of a separate small document, but can also see it 
being in the TLS draft or a bis of the SVCB document. Mainly that’s a question 
of who will spend the time to do the work, and where it will be easiest to get 
done. 

Tommy

> On Feb 24, 2023, at 6:33 AM, Ralf Weber  wrote:
> 
> Moin!
> 
>> On 23 Feb 2023, at 18:39, Warren Kumari wrote:
>> Instead of just having all of these document stuck indefinitely, I'm
>> proposing that we:
>> 1: Ask the RFC Editor to return the document to the IESG & IETF[1].
>> 2: I return it to the WG.
>> 3: The authors remove the bits that rely on ESNI
>> 4: The document progresses "normally" - it gets another WGLC, IETF LC, IESG
>> Eval, etc. Hopefully this can be expedited - it's already gone though all
>> of these steps once, and the updated document would be very similar to the
>> original.
>> 
>> 5: If / when tls-esni is published, the svcb-https authors submit a -bis
>> (while will likely just be 'git checkout '), and we
>> progress this just like any other WG document.
>> 
>> I've discussed this with the authors of the documents, the DNSOP and TLS
>> chairs, the relevant ADs and the full IESG.
>> 
>> However, before doing all this, I'd like to confirm that the WG doesn't
>> object to the plan….
> 
> I agree with this plan and as SVCB is already widely deployed and we need an
> RFC to point to and not a draft to get people not doing stupid things with it.
> 
> So long
> -Ralf
> ——-
> Ralf Weber
> 
> ___
> 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

Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

[Tommy Pauly]

Hello,

I support adoption of this draft. Adding more structured information will help 
clients provide more useful experiences when they encounter blocked/filtered 
error codes.

Best,
Tommy

> On Jan 22, 2023, at 12:36 PM, Tim Wicinski  wrote:
> 
> 
> All
> 
> The chairs have received feedback for DNSOP to adopt this document, and I've 
> wrestled with this document.We have received feedback when presented
> to adopt this work.  We've also had some conversations with folks who 
> offer DNS services to enterprises they have had some customer interest. 
> I will say personally that I am sure I can find some individuals at my 
> current employer who would get very interested in this also. 
> So the best thing to do is - see what the Working Group says.
> 
> If you work for someone who is interested in this, please let us know.
> If you work for someone who has customers interested in this, please let us 
> know.
> If you plan on implementing this (or not!), please let us know.
> 
> If you feel less comfortable speaking publicly, please reach out to the 
> chairs.
> 
> 
> This starts a Call for Adoption for draft-wing-dnsop-structured-dns-error-page
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-wing-dnsop-structured-dns-error-page/
> 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: February 5th, 2023
> 
> Thanks,
> tim wicinski
> For DNSOP co-chairs
> ___
> 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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Tommy Pauly]

I don’t personally find this proposal to be an improvement for clarity.

The fact that a client is SVCB-optional means, somewhat by definition, that 
they allow not using the SVCB results. Saying that the client “MAY” doesn’t 
really help; it’s the very definition of what SVCB-optional is. If the client 
doesn’t use non-SVCB connection modes at that point, then it is SVCB-reliant.

Listing out the details of what a non-SVCB connection does (not using the 
information from the SVCB record) also seems redundant. It is more accurate to 
just say “don’t use anything from SVCB if SVCB didn’t work” rather than trying 
to list out what all of those details might be.

Tommy

> On Aug 31, 2022, at 4:13 PM, Brian Dickson  
> wrote:
> 
> So, here is my suggestion, for "a sentence (or possibly two) which only 
> clarify what is already written?":
> 
> In section 3:
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
> becomes:
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>the authority endpoint's port number, and no SvcParams.
> 
> (The original didn't use RFC 2119 language, but the list of failure modes in 
> 3.1 leads to "MAY" being the most appropriate choice.)
> 
> Let me know if that is good enough.
> (The rest can go into a -bis... how soon are we allowed to start a -bis 
> document? The day of RFC publication? I'd like to start that as soon as 
> possible, while everything is still fresh.)
> 
> Brian
> 
> On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  > wrote:
>> 
>> 
>> 
>> 
>> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson 
>> mailto:brian.peter.dick...@gmail.com>> wrote:
>>> Here are some proposed text changes, per Warren's invitation to send text:
>> 
>> 
>> 
>> Um, no.  Warren said: "can we craft a sentence (or possibly two) which only 
>> clarify what is already written?". This is a significantly larger set of 
>> changes than that. The Section 3 changes in particular are (IMO) much more 
>> than a clarification. 
>> 
>> These may or may not be good changes, but anything approaching that level of 
>> change would have to be in a -bis document…
>> 
>> W
>> 
>> 
>>> 
>>> In section 1.2, change:
>>> 2.  TargetName: The domain name of either the alias target (for
>>>AliasMode) or the alternative endpoint (for ServiceMode).
>>> to:
>>> 2.  TargetName: Either the domain name of the alias target (for
>>>AliasMode) or the host name of the alternative endpoint (for 
>>> ServiceMode).
>>> 
>>> In section 2.4.2, change:
>>>As legacy clients will not know to use this record, service operators
>>>will likely need to retain fallback  and A records alongside this
>>>SVCB record, although in a common case the target of the SVCB record
>>>might offer better performance, and therefore would be preferable for
>>>clients implementing this specification to use.
>>> to:
>>>As legacy clients will not know to use this record, service operators
>>>will likely need to retain fallback  and A records at the service 
>>> name,
>>>although in a common case the target of the SVCB record
>>>might offer better performance, and therefore would be preferable for
>>>clients implementing this specification to use.
>>> 
>>> In section 2.4.3, change:
>>>In ServiceMode, the TargetName and SvcParams within each resource
>>>record associate an alternative endpoint for the service with its
>>>connection parameters.
>>> to:
>>>In ServiceMode, the TargetName and SvcParams within each resource
>>>record associate an alternative endpoint for the service with its
>>>connection parameters. The TargetName MUST be a host name
>>>(as defined in [DNSTerm].)
>>> 
>>> In section 3, the following changes are proposed; they introduce a new term 
>>> LASTNAME to be used to disambiguate the $QNAME reference so as to remove 
>>> ATTRLEAF prefixes from the appended target:
>>> 
>>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>>scheme (see Section 2.3).
>>> becomes:
>>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>>scheme (see Section 2.3). Let $LASTNAME be the service name without 
>>> any prefixes.
>>> 
>>> 
>>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>>following CNAMEs as normal), set $QNAME to its TargetName
>>>(without additional prefixes) and loop back to step 2, subject to
>>>chain length limits and loop detection heuristics (see
>>>Section 3.1).
>>> becomes:
>>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>>following CNAMEs as normal), set $QNAME to its TargetName
>>>(without additional prefixes), set 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Tommy Pauly]

On Aug 26, 2022, at 4:29 AM, Ben Schwartz  wrote:On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni  wrote:On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:

> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver.  To me, this implies that functional
> origin endpoints are likely to be required even if client software gains
> SVCB/HTTPS support.

This is why my suggested client behaviour was cognisant of this impediment.

    - If the client's *initial* SVCB lookup succeeds, *then* fallback is
      no longer an option.

    - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
      then the client behaves as though the SVCB record does not exist.

This results in more predictable behaviour, without optimising for
failure.I don't think "more predictable" is really a desirable or achievable outcome in this case.  Sophisticated clients (e.g. web browsers for HTTP, iterative resolvers for DNS) tend to develop highly tuned heuristics and state machines in pursuit of performance and reliability within their particular constraints.  I think an instruction not to fall back in this case would likely be ignored.  I definitely agree with all the points that Ben is making here and elsewhere. The practical realities of dealing with new record types, and the evolving heuristics on clients, will determine how the records are used. It makes sense for informational documents to talk about techniques and best practices—like an updated Happy Eyeballs algorithm to include SVCB logic, but that shouldn’t block anything in the base specification or add overly restrictive requirements today. TommyIt also strikes me as questionable from a standards perspective: if SVCB itself is optional, surely the client always has the right to change its mind and disable its support for SVCB?   If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).


> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.

Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients.In addition to the deployment concerns I've mentioned earlier, a deployment of this kind would be intrinsically insecure: a hostile intermediary could override the choice of which semantically distinct service is seen by the client.  That's another reason why this configuration is not permitted.  But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.The same could have been said of EDNS0 fallback, but the IETF wisely did not attempt to leap straight to that configuration in the initial RFC.  Instead, we gave client implementors plenty of room to tune their own fallback behaviors, and came back to tighten the system up much later when it became safe to do so.
> Viktor notes with concern that AliasMode is a "non-deterministic
> redirect".  Instead, the draft attempts to model the client behavior as a
> preference ordered stack of endpoints:
> 

I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.Indeed, I think this is a clarity/precision problem that we should correct.  Specifically, this "final value of $QNAME" endpoint is only used if it is not the initial value of $QNAME (i.e. if an AliasMode record was found).
Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/ records there, making some of the example
configurations in the draft impractical.I don't agree with this reading of RFC 1123.  There is no requirement that address records only be placed on hostnames, and there is no requirement that TargetName be a hostname.  If I were making an argument here, it might be about compatibility with RFC 8553 (Attrleaf), but hopefully this is mostly moot per the above.
___DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IANA Policy for SVCB

[Tommy Pauly]

If this space is not extensible from non-IETF RFCs, we’ll have missed the mark. 
The space is designed to be large (65K) to allow new work to easily use this 
extensibility. We don’t need to be too conservative with this space.

I disagree that there wouldn’t be good experts — we have authors of the 
document who have seen it through, and we have more people using this RR and 
gaining expertise.

Expert review is the right balance here.

Tommy

> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy  wrote:
> 
> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  > wrote:
> I am concerned that the set of Expert Reviewers necessary to handle SVCB 
> needs to have both expert DNS experience *and* detailed knowledge of the 
> SVCB model for this to work.
> 
> I am not sure there's anybody who fits that criteria.
> 
> Specification Required also assumes a community that can produce them, which 
> presumably contains the right experts.
> 
> Are we actually moving toward IETF Review here?
> 
> -MSK
> ___
> 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

Re: [DNSOP] IANA Policy for SVCB

[Tommy Pauly]

I agree with Paul that #2 seems to be best, with the expert being able to 
enforce a certain level of specification depending on the parameter being 
allocated.

Tommy

> On Mar 21, 2022, at 3:32 AM, Paul Wouters  wrote:
> 
> On Mon, 21 Mar 2022, Ben Schwartz wrote:
> 
>> This leaves us with several possible options:
>> 1. Change the MUST to SHOULD, or otherwise indicate that IANA is not 
>> expected to enforce anything about the contents of the format
>> reference.  Registrations might appear without a suitable format reference, 
>> resulting in keys that are difficult to parse and
>> serialize interoperably (e.g. same zone file produces different results in 
>> different authoritative server implementations).
>> 2. Change the registration policy to Expert Review, relying on the 
>> designated expert to enforce this rule.  Registrations might be
>> processed more slowly.
>> 3. Change the registration policy to Specification Required.  This is 
>> similar to #2 but incorporates formal guidance about what kinds
>> of documents qualify as a "specification" (e.g. must be "permanent and 
>> readily available").  Note that this is not "RFC Required":
>> any individual I-D is considered a qualified specification as soon as it is 
>> uploaded to the Datatracker.
> 
> I favour #2, especially as this intersects the DNS protocol with other
> protocols, and those requesting SVCB might not be DNS experts. Having
> a DNS expert to verify things make sense seems good. Although I would
> hope the Expert would also want a Specification Required as their
> input.
> 
> Paul
> 
> ___
> 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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Tommy Pauly]

> On May 19, 2021, at 2:37 PM, Erik Nygren  wrote:
> 
> 
> 
> 
>> On Wed, May 19, 2021 at 5:12 PM Tommy Pauly  wrote:
>> 
>> 
>>> On May 19, 2021, at 1:34 PM, Brian Dickson  
>>> wrote:
>>> 
>>> 
>>> 
>>> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  wrote:
>>>> I wanted to chime in on this discussion as a client-side implementor who 
>>>> has already widely deployed support for SVCB/HTTPS.
>>>> 
>>>> The current format, where the parameters are structured as a list within a 
>>>> single RR, is certainly simpler and less error prone for processing. Much 
>>>> of the information contained as parameters within the SVCB RR are useful 
>>>> for higher-level “application” logic. Within our deployment, the DNS stub 
>>>> resolver daemon receives the RR and does the parsing, and passes up the 
>>>> parameters bundle as a blob that is more or less opaque, to the layer that 
>>>> handles actual connection processing (doing happy eyeballs, protocol 
>>>> selection).
>>>> 
>>>> Processing the content of SVCB parameters must be handled atomically: the 
>>>> ALPN, ECH config, and any other information must be handled clearly as a 
>>>> unit and not have any chance of being broken up. Lots of code is already 
>>>> based on processing RRs as chunks of data, and requiring anyone looking at 
>>>> the information to stitch the parameter list back together based on 
>>>> multiple RRs that must be in a particular order adds complexity and 
>>>> invites in bugs and errors.
>>>> 
>>>> I’d strongly encourage sticking with the wire image we’ve already been 
>>>> using and deploying.
>>> 
>>> Would it be accurate to say that as long as the wire format of both SVCB 
>>> and HTTPS do not change, your client implementation(s) would not be 
>>> impacted by any changes to zone file format?
>>> 
>>> I.e. you don't implement any server code, so what the zone format is does 
>>> not affect you, and how the wire format gets produced from the zone format 
>>> is not relevant to you?
>> 
>> That’s correct. My main concern here is keeping the wire format consistent 
>> and simple. How the zone format file works is indeed something separate, and 
>> not something I have strong opinions on. Anything we can do to make the 
>> processing simple for both sides is great.
>> 
> 
> Also as I understand it, changes that substantially change the semantics of 
> the records but preserving
> the presentation format and wire format would also affect you?  In 
> particular, any shift from
> a RR-per-service-binding to having service bindings span RRs in the RRset 
> would add significant
> complexity to your client implementation as you've described?

Correct. I’m saying that the wire format should remain as defined, as well as 
the contents and semantics—the single RR containing the various parameters 
needed to interpret a single service instance, with ALPN/ECH/Hints all 
together. Changing the way this service is spelled, such as breaking it into 
separate RRs, effectively breaks the wire format (since it is no longer 
intelligible as a single service). 
> 
> Separately I've opened https://github.com/MikeBishop/dns-alt-svc/issues/324
> to explore if there are ways we can simplify through character set 
> constraints.
> In-particular, if we could get ALPN constrained to a set of token characters
> (and similarly constrain future SvcParams that want to be value lists to use 
> a limited subset of characters)  then some of the parsing concerns get 
> simpler.
> I've mailed the TLS WG as they may not be willing to change how ALPN registry
> entries are handled in which case we'd still need a solution here.
> 
> Best, Erik
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Tommy Pauly]

> On May 19, 2021, at 1:34 PM, Brian Dickson  
> wrote:
> 
> 
> 
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  <mailto:tpa...@apple.com>> wrote:
> I wanted to chime in on this discussion as a client-side implementor who has 
> already widely deployed support for SVCB/HTTPS.
> 
> The current format, where the parameters are structured as a list within a 
> single RR, is certainly simpler and less error prone for processing. Much of 
> the information contained as parameters within the SVCB RR are useful for 
> higher-level “application” logic. Within our deployment, the DNS stub 
> resolver daemon receives the RR and does the parsing, and passes up the 
> parameters bundle as a blob that is more or less opaque, to the layer that 
> handles actual connection processing (doing happy eyeballs, protocol 
> selection).
> 
> Processing the content of SVCB parameters must be handled atomically: the 
> ALPN, ECH config, and any other information must be handled clearly as a unit 
> and not have any chance of being broken up. Lots of code is already based on 
> processing RRs as chunks of data, and requiring anyone looking at the 
> information to stitch the parameter list back together based on multiple RRs 
> that must be in a particular order adds complexity and invites in bugs and 
> errors.
> 
> I’d strongly encourage sticking with the wire image we’ve already been using 
> and deploying.
> 
> Would it be accurate to say that as long as the wire format of both SVCB and 
> HTTPS do not change, your client implementation(s) would not be impacted by 
> any changes to zone file format?
> 
> I.e. you don't implement any server code, so what the zone format is does not 
> affect you, and how the wire format gets produced from the zone format is not 
> relevant to you?

That’s correct. My main concern here is keeping the wire format consistent and 
simple. How the zone format file works is indeed something separate, and not 
something I have strong opinions on. Anything we can do to make the processing 
simple for both sides is great.

> 
> Thank you for the details on how your client uses the wire format and the way 
> those impact the end client systems.

Absolutely! Happy to answer any further questions as well.

Best,
Tommy
> 
> Brian

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Tommy Pauly]

I wanted to chime in on this discussion as a client-side implementor who has 
already widely deployed support for SVCB/HTTPS.

The current format, where the parameters are structured as a list within a 
single RR, is certainly simpler and less error prone for processing. Much of 
the information contained as parameters within the SVCB RR are useful for 
higher-level “application” logic. Within our deployment, the DNS stub resolver 
daemon receives the RR and does the parsing, and passes up the parameters 
bundle as a blob that is more or less opaque, to the layer that handles actual 
connection processing (doing happy eyeballs, protocol selection).

Processing the content of SVCB parameters must be handled atomically: the ALPN, 
ECH config, and any other information must be handled clearly as a unit and not 
have any chance of being broken up. Lots of code is already based on processing 
RRs as chunks of data, and requiring anyone looking at the information to 
stitch the parameter list back together based on multiple RRs that must be in a 
particular order adds complexity and invites in bugs and errors.

I’d strongly encourage sticking with the wire image we’ve already been using 
and deploying. I like Erik’s suggestion that we solve the issues with parsing 
by putting more rules and constraints of the set of available characters, etc. 

Best,
Tommy

> On May 17, 2021, at 2:58 PM, Erik Nygren  wrote:
> 
> 
> On Mon, May 17, 2021 at 5:36 PM Ben Schwartz 
> mailto:40google@dmarc.ietf.org>> 
> wrote:
> 
> 
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson  > wrote:
> 
> 
> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz  > wrote:
> 
> 
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson  > wrote:
> 
> 
> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz  > wrote:
> ... 
> Breaking the binding into pieces creates many new opportunities for error, 
> such as having multiple TargetNames in a single binding.  It corresponds to a 
> multimap datastructure instead of a standard map.  Every attribute of each 
> binding would naturally be an unordered collection, which is a bad fit for 
> attributes that are required to be singular, or an ordered list, or anything 
> other than a set.
> ... 
> So, taking your observations about TargetName into account, and borrowing 
> from the overloading of Priority to signal AliasMode, here's an alternative 
> that I think addresses most of the concerns.
> Priority {AliasTarget | ServiceTarget | KeyName} {ServiceBindingPriorityValue 
> | Value}
> where
> Priority == 0 => AliasMode
> Priority >0, <128 => ServiceMode
> Priority > 128 => ServiceBinding key-value record 
> 
> The same example would be encoded (again with only RDATA values):
> 1 target "h3pool" 128
> 128 alpn "h2,h3"
> 128 ech "123..."
> 2 target "." 129
> 129 alpn "h2"
> 129 ech "abc..." 
> 
> I find this format, with multiple lines and multiple integers per binding, 
> much more difficult to read or write than the current draft, especially since 
> the elements of each binding can potentially be spread across a zone file 
> (perhaps by accident) in arbitrary order.
> 
> 
> I concur with Ben here.  Thank you for spelling out and proposing this 
> alternative, but this seems much less usable
> and understandable by a typical user, either for zone publication or for 
> reading diagnostic output from tools 
> like "dig" or for talking about in other drafts specifying SVCB.  
> 
> Side-note: some precursors to SVCB and earlier discussions in the working 
> group
> proposed using a standardized format such as CBOR for encoding the SvcParams 
> but
> that approach was discarded as bringing in a bunch of its own baggage and 
> being too
> different from typical DNS usage.
> 
> An approach HTTP took was to define "Structured Field Values for HTTP" 
> (rfc8941)
> which may be more complexity than is needed here, but perhaps there
> is a similar approach that could work for SVCB of defining explicit types
> for SvcParamValues?
> 
> Another approach could be seeing if there was a way to require
> everything to use a limited character set and require escaping
> for things outside of these constraints.  For example, alpn values
> with a limited set of token characters would be allowed as strings,
> but anything else would need escaping.  Would require base64 encoding
> of SvcParamValues wanting characters outside of "non-special" 
> be easier to parse, perhaps with a prefix to indicate that a string is base64 
> type?
> Are there other similar things that would keep the format similar to the 
> existing
> format but reduce the number of parser special-cases needed?
> 
>  Erik
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

[Tommy Pauly]

> On Mar 17, 2021, at 6:04 PM, Ben Schwartz 
>  wrote:
> 
> Release notes for this revision:
>   *  Simplify the IANA instructions (pure First Come First Served)
>   *  Recommend against publishing chains of >8 aliases
>   *  Clarify requirements for using SVCB with a transport proxy
>   *  Adjust guidance for Port Prefix Naming
>   *  Minor editorial updates
> 
> I'm only aware of one outstanding issue: a proposal to change the name of the 
> "echconfig" key to "ech".  This key corresponds to a value that is an 
> "ECHConfigList", which is a collection of "ECHConfig" structs, and some 
> implementers have reported that the singular/plural name-value mismatch 
> created confusion.  This issue is discussed in detail here: 
> https://github.com/MikeBishop/dns-alt-svc/pull/299 
> .
> 
> This name has no effect on queries, responses, or zone transfers, but it does 
> appear in zone files.  Zone files will not be portable between 
> implementations that use different names.  This is true whether we "burn" the 
> current codepoint and allocate a new one, or simply rename the current 
> codepoint.  However, using a new codepoint would allow updated 
> implementations to support both names, facilitating zone file portability in 
> one direction.  It would also be possible to support the old name with 
> special-case name aliasing logic.
> 
> In my view, the temporary portability benefit is too small to justify the 
> permanent registry pollution of a deprecated codepoint, especially because 
> ECH itself is not yet finalized, and there are no deployments except for 
> standards development purposes.  However, others have disagreed.  We'll need 
> to reach consensus before making any changes here.

Personally, I’d prefer to see the name change, and not burn a codepoint, as 
long as we’re not breaking any zone files.

I think the question is: does anyone have a zone that has actually deployed the 
echconfig parameter? I see many responses with SVCB/HTTPS records, but none 
with the echconfig in practice. If someone is aware of a production deployment 
that can’t move, please speak up!

Tommy

> 
> --Ben
> 
> On Wed, Mar 17, 2021 at 1:11 PM  > wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : Service binding and parameter specification via the 
> DNS (DNS SVCB and HTTPS RRs)
> Authors : Ben Schwartz
>   Mike Bishop
>   Erik Nygren
> Filename: draft-ietf-dnsop-svcb-https-04.txt
> Pages   : 48
> Date: 2021-03-17
> 
> Abstract:
>This document specifies the "SVCB" and "HTTPS" DNS resource record
>(RR) types to facilitate the lookup of information needed to make
>connections to network services, such as for HTTPS origins.  SVCB
>records allow a service to be provided from multiple alternative
>endpoints, each with associated parameters (such as transport
>protocol configuration and keys for encrypting the TLS ClientHello).
>They also enable aliasing of apex domains, which is not possible with
>CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
>origins.  By providing more information to the client before it
>attempts to establish a connection, these records offer potential
>benefits to both performance and privacy.
> 
>TO BE REMOVED: This document is being collaborated on in Github at:
>https://github.com/MikeBishop/dns-alt-svc 
>  [1].  The most recent
>working version of the document, open issues, etc. should all be
>available there.  The authors (gratefully) accept pull requests.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ 
> 
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04 
> 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org 
> .
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ 
> 
> 
> 

Re: [DNSOP] SVCB proposals

[Tommy Pauly]

Hi Ben,

Thanks for the work on the SVCB draft! It’s in really good shape, in my 
opinion. I’ve commented on these three PRs, but I’ll share my thoughts here as 
well.

> On Feb 18, 2021, at 7:36 AM, Ben Schwartz 
>  wrote:
> 
> The SVCB/HTTPS RR draft is nearing completion, but there are a few remaining 
> topics on which the authors would appreciate feedback from the working group. 
>  Personally, I've written up three proposed changes that would benefit from 
> broader input.  Please share your thoughts.
> 
> 1. Change IANA policy to Specification Required
> (https://github.com/MikeBishop/dns-alt-svc/pull/262/files 
> )
> 
> The current proposed IANA policy for SvcParamKeys has allocatable ranges 
> under three different policies ("Standards Action", "Expert Review", and 
> "First Come First Served").  This is very flexible and enables 
> experimentation, but creates compatibility risk: a FCFS SvcParamKey could be 
> allocated without a clear specification of its zone file syntax, leading to 
> zone file portability issues.
> 
> This proposal would replace all these ranges with a uniform Specification 
> Required policy.  The required documentation is minimal: it is only required 
> to describe the zone file format.

I disagree with the rationale behind this change. I totally agree that we 
should have a clear zone file syntax, but based on RFC 8126 that defines the 
various buckets, FCFS registrations can have requirements for well-formatted 
entries with registry-specific requirements. We can mandate that the 
registration have a clear zone file syntax, without needing to be Specification 
Required. Specification Required requires expert review and is a heavier-weight 
process than what we necessarily need for an experimental range. 

The documentation that’s needed is minimal: the value, the name, and the zone 
file format. These can be entries directly in the registry, and will make the 
registry a more useful resource.

> 
> 2. Skip the default port prefix
> (https://github.com/MikeBishop/dns-alt-svc/pull/230/files 
> )
> 
> Using SVCB with a new protocol requires the initial QNAME to end with 
> _(scheme).$HOSTNAME.  The current text suggests (non-normatively) to add 
> _$PORT for endpoints that are identified by a port number.  This turns out to 
> be inelegant for protocols that almost always use the default port.  For 
> example, in the DNS mapping (draft-schwartz-svcb-dns), this would correspond 
> to names like "_53._dns.resolver.example".
> 
> This proposal would change the guidance to skip the port prefix when starting 
> with the default port (like "_dns.resolver.example").

This is a good change. Ship it!

> 
> 3. Add a SHOULD-level chain length limit for zone owners
> https://github.com/MikeBishop/dns-alt-svc/pull/294/files 
> 
> 
> Constructing huge chains of CNAME and AliasMode records is clearly a bad 
> idea, but how huge is too huge?  This change suggests not to use more than 8. 
>  This doesn't change the requirements for resolvers (which are free to impose 
> any limit greater than zero) but it might help us to converge on common 
> behavior.

This seems like a sensible change. I think the recommendation could be less 
that 8, but it shouldn’t be more. Leaving this at 8 seems fine.

Best,
Tommy
> 
> --Ben Schwartz
> ___
> 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

Re: [DNSOP] SVCB and the specialness of _

[Tommy Pauly]

> On Oct 7, 2020, at 12:26 PM, Ben Schwartz 
>  wrote:
> 
> 
> 
> On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson  > wrote:
> 
> 
> On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz  > wrote:
> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson  > wrote:
> 
> Other than the syntactic brevity, is there any functional difference to the 
> client between a TargetName of "." versus a TargetName of "$HOSTNAME" in the 
> description above?
> 
> Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are 
> applied).  With the proposed change, "." would always mean $HOSTNAME when a 
> ServiceMode record is returned directly for the original query.  However, if 
> the ServiceMode record is reached via a CNAME or AliasMode record, then "." 
> does not correspond to (the original) $HOSTNAME.
> 
> This presents two significant problems.
> 
> First, this (what you write above) means that "." will not be guaranteed 100% 
> of the time to result in the "correct" value, if I understand correctly.
> 
> I'm not sure what you mean by "correct".  With or without this proposal, the 
> expanded name for "." is well-defined.
> 
> Second, the use of "." by whoever creates the ServiceMode record may not be 
> aware of how it is reached (e.g. by CNAME or AliasMode records not under 
> their control or that they are aware of or which may be added later).
> 
> The expanded name does not depend on how the record was reached.  I'm merely 
> trying to point out that, after an alias has been followed, any information 
> about "$HOSTNAME" has been lost.

+1. The “.” is very clear in meaning, since it is only referring to a name that 
is in the record itself. It’s not about where the chain comes from. This 
proposal is only about cleaning up a case where that name in the record has 
less helpful “_foo" prefixes. We absolutely should keep the “.” meaning as-is 
for all other cases.

Tommy

> 
> ...
> As you note below, "@" is available, and while perhaps not as elegant, is 
> handled in the authority server's loading of zone files, and never results in 
> dynamic processing or additional handling requirements. I.e. it achieves 
> maybe 90% of the intended "happy" result, but does so with 100% 
> interoperability after the zone itself is constructed and loaded.
> 
> My impression is that "@" is always, or nearly always, a zone apex.  I expect 
> that the majority of HTTPS and SVCB records will not be for the zone apex.  
> Setting a ServiceMode TargetName of @ would instruct those records to use the 
> A/ records for the apex name.  This strikes me as an unlikely 
> configuration.
> 
>  
> 
> First, is the use of the standard zone file construct of "@", which only 
> exists within the zone master file, and gets substituted on import with 
> whatever $ORIGIN is.
> 
> Yes, the syntax already supports "@" and relative names when writing out a 
> TargetName in the zone file.  This is useful, but I don't think it has the 
> effect of guiding users toward a good configuration.
> 
> Brian 
> ___
> 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

Re: [DNSOP] SVCB and the specialness of _

[Tommy Pauly]

This change seems reasonable, and makes “.” still more useful for the generic 
SVCB case.

Thanks,
Tommy

> On Oct 6, 2020, at 4:51 PM, Ben Schwartz  
> wrote:
> 
> Hi DNSOP,
> 
> There was recently an interesting proposal [1] for a change to the SVCB draft 
> that seems to merit input from the working group.
> 
> Background:
> When using SVCB, clients append an underscore prefix ("Attrleaf") to the 
> name, containing the "scheme".  When there is an actual URI involved this 
> will literally be the URI scheme, e.g. _ftp.ftp.example.net 
> .  Schemes can prepend additional 
> underscore-prefix labels to encode scheme-specific service identifiers; the 
> only anticipated use for this is a port number (e.g. 
> _8080._https.www.example.com ).
> 
> SVCB also contains a small optimization: In ServiceMode, if the TargetName is 
> ".", this means "use the address records for the owner name".  This reduces 
> packet size (since name compression is not possible in new RR types), but 
> more importantly, it makes zone file editing easier and guides zone owners 
> toward the "happy path", where there is no latency penalty because the 
> resolver has already requested the corresponding address records.
> 
> This construction works well for HTTPS on port 443, and for any lookup 
> following an AliasMode record, because in those cases the SVCB/HTTPS, A, and 
>  queries all share the same QNAME.  However, it does not work when the 
> initial query has underscore labels and returns a ServiceMode record, because 
> the ServiceMode record's name is not the hostname (due to the underscore 
> labels).
> 
> Proposal:
> The proposal would change the meaning of "." from "Use the SVCB record's 
> owner name" to "Use the SVCB record's owner name *minus any leading 
> underscore labels*".
> 
> Pro: TargetName = "." would now coincide with the "happy path" in all 
> ordinary cases.
> * Simpler guidance to zone owners (always prefer ".")
> * Clearer design rationale ("." is where the address queries already went)
> * Shorter RDATA in the "happy path" case (for some non-HTTPS uses)
> 
> Con:
> * Servers (recursive and authoritative) that perform Additional Section 
> processing would have to implement this underscore-label stripping procedure. 
>  This would be a rare violation of DNS's usual abstraction barrier (servers 
> don't normally discriminate based on the format of labels).
> * There could be a change of operational control (e.g. zone cut or CNAME) 
> between _port._scheme.$HOSTNAME and $HOSTNAME, in which case the ServiceMode 
> record might actually prefer to use address records at its own name, despite 
> the latency cost.
> * This gets very tricky if an AliasMode or CNAME target contains underscore 
> prefixes.  It may be impossible to stay on the "happy path" in all these 
> cases.
> 
> [1] https://github.com/MikeBishop/dns-alt-svc/issues/252 
> 
> ___
> 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

Re: [DNSOP] DNS HTTPS/SVCB record type support in iOS 14

[Tommy Pauly]

> On Sep 26, 2020, at 5:01 AM, Ian Swett  
> wrote:
> 
> 
> 
>> On Fri, Sep 25, 2020 at 10:09 PM Tommy Pauly 
>>  wrote:
>> Hi Jana,
>> 
>> Currently, HTTP/3 support in Safari needs to be enabled by the user (under 
>> Experimental Features). When it is enabled, the ALPN hint in the HTTPS 
>> record causes the stack to race QUIC first (assuming we have no history of 
>> QUIC failures), even when no previous connections had been made to the host. 
> 
> What if there is a history of QUIC failures and what constitutes a failure?  
> And is the history per-host, per-user or some combination thereof?
> 
> I'm curious how this logic compares to Chrome's current logic.

We store a history of success/failure/losing the race on a per-host basis. This 
is based on our logic for racing IPv6 and IPv4 for happy eyeballs. If we have 
no successful QUIC connections within a certain period of time, but have a 
number of failures or lost races above a threshold (~10), we’ll race with TCP 
first. If a failure is detected at the H3 layer (not in the race or in the QUIC 
handshake), we have a lower threshold before swapping the race order. 

Thanks,
Tommy 

> 
> Thanks, Ian
>  
>> 
>> Thanks,
>> Tommy
>> 
>>>> On Sep 25, 2020, at 6:08 PM, Jana Iyengar  wrote:
>>>> 
>>> 
>>> Thanks for sharing this, Tommy -- this is exciting indeed.
>>> Can you share if Safari uses this information for deciding when to race a 
>>> QUIC connection?
>>> 
>>> - jana
>>> 
>>>> On Fri, Sep 25, 2020 at 1:19 PM Tommy Pauly 
>>>>  wrote:
>>>> Hi David,
>>>> 
>>>> Sorry for the lack of clarity! The HTTPS query will be made alongside 
>>>> A/ queries for all connections that use Network.framework/NSURLSession 
>>>> for URL schemes “http://“ and “https://“, or TCP port 80 or port 443.
>>>> 
>>>> Thanks,
>>>> Tommy
>>>> 
>>>>> On Sep 25, 2020, at 1:12 PM, David Schinazi  
>>>>> wrote:
>>>>> 
>>>>> Hi Tommy,
>>>>> 
>>>>> Thanks for the announcement! It's really exciting to see this deployed in 
>>>>> the wild.
>>>>> Clarification question: your email mentioned support for the HTTPS DNS 
>>>>> query,
>>>>> but it didn't mention when iOS makes those queries. For example, do you 
>>>>> query
>>>>> this record every single time you perform A/ queries? (in the context 
>>>>> of
>>>>> a Network.framework connection to port 443)
>>>>> 
>>>>> David
>>>>> 
>>>>> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly 
>>>>>  wrote:
>>>>>> Hello DNSOP & QUIC,
>>>>>> 
>>>>>> I wanted to provide an update that the production version of iOS 14, 
>>>>>> which shipped last week, includes support for sending HTTPS (SVCB) DNS 
>>>>>> queries (RR type 65) for applications using our system networking APIs.
>>>>>> 
>>>>>> The implementation status has been updated here: 
>>>>>> https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
>>>>>> 
>>>>>> For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 
>>>>>> experimental support is enabled) iOS will use the ALPN indication in the 
>>>>>> HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. 
>>>>>> As previously noted on the DNSOP list, Cloudflare is already supporting 
>>>>>> publishing these records, and we’d encourage other server deployments 
>>>>>> that support QUIC to do the same.
>>>>>> 
>>>>>> To note, this behavior is the same in the betas of macOS 11.
>>>>>> 
>>>>>> Best,
>>>>>> Tommy
>>>>> ___
>>>>> 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

Re: [DNSOP] DNS HTTPS/SVCB record type support in iOS 14

[Tommy Pauly]

Hi Jana,

Currently, HTTP/3 support in Safari needs to be enabled by the user (under 
Experimental Features). When it is enabled, the ALPN hint in the HTTPS record 
causes the stack to race QUIC first (assuming we have no history of QUIC 
failures), even when no previous connections had been made to the host. 

Thanks,
Tommy

> On Sep 25, 2020, at 6:08 PM, Jana Iyengar  wrote:
> 
> 
> Thanks for sharing this, Tommy -- this is exciting indeed.
> Can you share if Safari uses this information for deciding when to race a 
> QUIC connection?
> 
> - jana
> 
>> On Fri, Sep 25, 2020 at 1:19 PM Tommy Pauly 
>>  wrote:
>> Hi David,
>> 
>> Sorry for the lack of clarity! The HTTPS query will be made alongside A/ 
>> queries for all connections that use Network.framework/NSURLSession for URL 
>> schemes “http://“ and “https://“, or TCP port 80 or port 443.
>> 
>> Thanks,
>> Tommy
>> 
>>> On Sep 25, 2020, at 1:12 PM, David Schinazi  
>>> wrote:
>>> 
>>> Hi Tommy,
>>> 
>>> Thanks for the announcement! It's really exciting to see this deployed in 
>>> the wild.
>>> Clarification question: your email mentioned support for the HTTPS DNS 
>>> query,
>>> but it didn't mention when iOS makes those queries. For example, do you 
>>> query
>>> this record every single time you perform A/ queries? (in the context of
>>> a Network.framework connection to port 443)
>>> 
>>> David
>>> 
>>> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly 
>>>  wrote:
>>>> Hello DNSOP & QUIC,
>>>> 
>>>> I wanted to provide an update that the production version of iOS 14, which 
>>>> shipped last week, includes support for sending HTTPS (SVCB) DNS queries 
>>>> (RR type 65) for applications using our system networking APIs.
>>>> 
>>>> The implementation status has been updated here: 
>>>> https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
>>>> 
>>>> For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 
>>>> experimental support is enabled) iOS will use the ALPN indication in the 
>>>> HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. As 
>>>> previously noted on the DNSOP list, Cloudflare is already supporting 
>>>> publishing these records, and we’d encourage other server deployments that 
>>>> support QUIC to do the same.
>>>> 
>>>> To note, this behavior is the same in the betas of macOS 11.
>>>> 
>>>> Best,
>>>> Tommy
>>> ___
>>> 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

Re: [DNSOP] DNS HTTPS/SVCB record type support in iOS 14

[Tommy Pauly]

Hi David,

Sorry for the lack of clarity! The HTTPS query will be made alongside A/ 
queries for all connections that use Network.framework/NSURLSession for URL 
schemes “http://“ and “https://“, or TCP port 80 or port 443.

Thanks,
Tommy

> On Sep 25, 2020, at 1:12 PM, David Schinazi  wrote:
> 
> Hi Tommy,
> 
> Thanks for the announcement! It's really exciting to see this deployed in the 
> wild.
> Clarification question: your email mentioned support for the HTTPS DNS query,
> but it didn't mention when iOS makes those queries. For example, do you query
> this record every single time you perform A/ queries? (in the context of
> a Network.framework connection to port 443)
> 
> David
> 
> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly 
> mailto:40apple@dmarc.ietf.org>> wrote:
> Hello DNSOP & QUIC,
> 
> I wanted to provide an update that the production version of iOS 14, which 
> shipped last week, includes support for sending HTTPS (SVCB) DNS queries (RR 
> type 65) for applications using our system networking APIs.
> 
> The implementation status has been updated here: 
> https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md 
> <https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md>
> 
> For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 
> experimental support is enabled) iOS will use the ALPN indication in the 
> HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. As 
> previously noted on the DNSOP list, Cloudflare is already supporting 
> publishing these records, and we’d encourage other server deployments that 
> support QUIC to do the same.
> 
> To note, this behavior is the same in the betas of macOS 11.
> 
> Best,
> Tommy
> ___
> 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] DNS HTTPS/SVCB record type support in iOS 14

[Tommy Pauly]

Hello DNSOP & QUIC,

I wanted to provide an update that the production version of iOS 14, which 
shipped last week, includes support for sending HTTPS (SVCB) DNS queries (RR 
type 65) for applications using our system networking APIs.

The implementation status has been updated here: 
https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md 


For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 
experimental support is enabled) iOS will use the ALPN indication in the HTTPS 
record to enable HTTP/3 prior to receiving an Alt-Svc indication. As previously 
noted on the DNSOP list, Cloudflare is already supporting publishing these 
records, and we’d encourage other server deployments that support QUIC to do 
the same.

To note, this behavior is the same in the betas of macOS 11.

Best,
Tommy___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

[Tommy Pauly]

> On Jul 22, 2020, at 5:46 PM, Wellington, Brian 
>  wrote:
> 
> I attempted to start implementing support for SVCB and HTTPS, and discovered 
> that the data being served by Cloudflare does not conform to the current spec.
> 
> Assuming my decoder is correct, the response below decodes to:
> 
> 1 . alpn=h3-29,h3-28,h3-27,h2 echconfig=aBIaLmgSGy4= 
> ipv6hint=2606:4700::6812:1a2e,2606:4700::6812:1b2e
> 
> and does not include a “mandatory” parameter.  But section 6.5 of 
> draft-ietf-dnsop-svcb-https, which is talking about the “mandatory” key, says:
> 
>   This SvcParamKey is always automatically mandatory,
> 
> which implies that there MUST be a “mandatory” parameter.  Is this an 
> oversight in the Cloudflare implementation, or is the Cloudflare 
> implementation not implementing the current version?

The Cloudflare record does conform correctly.

The “mandatory” key does NOT need to be included. "automatically mandatory” 
keys do not need to be included. Mandatory just indicates which 
non-automatically-mandatory keys included in the record are required to be 
understood by clients, or else clients should reject them.

Thanks,
Tommy

> 
> Thanks,
> Brian
> 
>> On Jul 16, 2020, at 8:13 AM, Alessandro Ghedini > > wrote:
>> 
>> Hello,
>> 
>> Just a quick note that we have started serving "HTTPS" DNS records from
>> Cloudflare's authoritative DNS servers. Our main use-case right now is
>> advertising HTTP/3 support for those customers that enabled that feature (in
>> addition to using Alt-Svc HTTP headers).
>> 
>> If anyone is interested in trying this out you can query pretty much all 
>> domains
>> served by Cloudflare DNS for which we terminate HTTP.
>> 
>> For example:
>> 
>>  % dig blog.cloudflare.com type65
>> 
>> ; <<>> DiG 9.16.4-Debian <<>> blog.cloudflare.com type65
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17291
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;blog.cloudflare.com.IN  TYPE65
>> 
>> ;; ANSWER SECTION:
>> blog.cloudflare.com. 300 IN  TYPE65  \# 76 
>> 00010100150568332D32390568332D32380568332D3237026832 
>> 0004000868121A2E68121B2E0006002026064700 
>> 68121A2E2606470068121B2E
>> 
>> Cheers
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w=Ei0lUqjTt2OhRnRqJeO1XDCHQqnH1FdINDMcPEhCC1g=WQn55KFIZ5LGfsj-QGNSS31WGhpI-GuXpJEmhibwNuo=
>>  
>> 
>>  
> 
> ___
> 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

Re: [DNSOP] HTTPS and SVBC key names.

[Tommy Pauly]

This is only the presentation format—in wire format, these are alway 2-byte 
integers. Thus, there isn’t any effect on packet size.

Thanks,
Tommy

> On Jul 15, 2020, at 10:34 AM, Ólafur Guðmundsson 
>  wrote:
> 
> DoU i.e. DNS over UDP packet size impact,
>  
> Olafur
> 
> 
> On Wed, Jul 15, 2020 at 1:16 PM Erik Nygren  > wrote:
> We landed on 63 in the draft version we just published  (to align with max 
> label lengths).
> There's no reason they *need* to be short as they are just in presentation 
> form, so their length
> comes down to usability and finding the right words.  The longest currently 
> is 15 and it would
> be better to avoid future ones needing to be artificially constrained.  Is 
> there a reason we'd
> want to decrease this (eg, to 31)?
> 
> On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson  > wrote:
> How about 2 or 10 ? 
> why do  the names to need to be long ? 
> 
> Olafur 
> 
> 
> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  > wrote:
> Or 64?  
> 
> 
> 
> - Erik
> 
>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
> 
> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz  > wrote:
> How about 255 characters?
> 
> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  > wrote:
> Can we please have a length limit on key names?  At the moment they could be 
> a billion characters long as they don’t go over the wire..
> -- 
> 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 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> 
> 
> -- 
> Ólafur Gudmundsson | Engineering Director 
> www.cloudflare.com  blog.cloudflare.com 
> 
> 
> -- 
> Ólafur Gudmundsson | Engineering Director 
> www.cloudflare.com  blog.cloudflare.com 
> ___
> 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

Re: [DNSOP] HTTPS and SVBC client support measurement.

[Tommy Pauly]

> On Jul 9, 2020, at 5:27 PM, Ben Schwartz  
> wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews  > wrote:
> It would be useful if there was a way to measure client support for HTTPS and 
> SVBC even when they are not in use.  Perhaps a HTTP header could be added to 
> signal that the client supports HTTPS? This will provide server 
> administrators information about their client population to decide when it is 
> safe to remove support for legacy clients.
> 
> I don't foresee anyone removing support for non-SVCB-aware clients (I 
> wouldn't call them "legacy") any time soon.  That sounds like a change that 
> would take many decades, if it even proves desirable.
> 
> However, I think your purpose here is already well-served by the current 
> draft.  If you publish SVCB records that point to a different server IP 
> address or port from the non-SVCB connections, you can easily observe what 
> fraction of users are SVCB-enabled.

Yes, this seems like the simplest way to track this from the server standpoint. 
That does require having a server listening on another port/address, but 
presumably if you’re getting benefit from SVCB, you probably have something 
you’re pointing to.

We can imagine a world once most clients are HTTPS/SVCB-aware that the A and 
 records stop being used for load balancing, but just point to the 
“fallback” configuration, and servers can detect support for HTTPS/SVCB in 
client by detecting the use of those services. 

> 
> -- 
> 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
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS SVCB no service available signal.

[Tommy Pauly]

+1

When implementing the client, this case needs to be caught anyhow (the error of 
aliasing to your own domain), so it has the effect of indicating that no 
service is valid. This suggestion turns this case from an error (which still 
had the desired effect), to a proper signal.

Tommy

> On Jul 9, 2020, at 2:18 PM, Ben Schwartz  
> wrote:
> 
> This seems like a reasonable idea to me.  We should be able to incorporate 
> this for the next draft revision.
> 
> On Thu, Jul 9, 2020 at 3:42 PM Mark Andrews  > wrote:
> We should use “HTTPS 0 .” to signal that there is no service offered. 
> Similarly for SVCB. 
> 
> Currently “.” has no useful purpose in the alias form.
> 
> -- 
> Mark Andrews
> ___
> 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
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-https

[Tommy Pauly]

> On Jun 17, 2020, at 5:10 AM, libor.peltan  wrote:
> 
> Hi all,
> 
> i'm a developer of Knot DNS authoritative server. I have some comments on the 
> SVCB draft and some suggestions for improvements. Just consider my thoughts 
> and then do whatever is best.
> 
> (1) The format of SVCB (and HTTPS) RR is too complicated, especially for 
> parsing presentation format to wireformat and back, including consistency 
> checks. Perhaps instead of
> 
> www 3600 IN HTTPS 1 . alpn=h2 port=8443
> 
> It could be
> 
> www 3600 IN HTTPS 1 . alpn h2
>   1 . port 8443
> 
> Which gives slightly bigger RRSet wireformat, but not by much.

I find this format suggestion to be far more confusing to read, since these 
really are key-value pairs, and the SvcDomainName and the SvcDomainPriority 
fields are shared across the different key-value pairs.

What specifically is too hard to parse in the draft’s format? Is that something 
that more clarifying examples can help with instead?

Tommy

> 
> (2) Paragraph 2.2 explicitly requires that SvcDomainName must not be 
> compressed. Is there a reason? Especially when the response packets are large 
> (and I expect that for SVCB they will), any compression helps.
> 
> (3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of a 
> domain that has SVCB, , or A records" versus "SvcDomainName MAY be the 
> owner of a CNAME record". What is the meaning here?
> 
> (4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 4.1 is 
> too vague and I don't see what an authoritative (not recursive!) server shall 
> answer in situation SVCB->CNAME->A (all in-bailiwick). Shall the CNAME and A 
> be added to additional section? For comparison, in situation MX->CNAME->A we 
> don't bother since this situation is forbidden (see RFC 2181).
> 
> (5) Wouldn't one octet for priority field be enough?
> 
> (6) There are not enough examples in the document. There are many variants of 
> SVCB records, the formal ABNF description is difficult to read, and it would 
> also illustrate what kind of services those records are designed to handle.
> 
> Best regards and thanks for your effort,
> 
> Libor Peltan
> CZ.NIC
> 
> ___
> 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

Re: [DNSOP] Are SVCB/HTTPSSVC going to be renamed after all?

[Tommy Pauly]

That sounds great! Thanks to the authors for getting so many issues cleared up 
recently. The new version is looking good.

As an implementor, I’d like to voice my support for getting the early code 
point allocation soon.

Best,
Tommy 

> On Jun 12, 2020, at 1:43 PM, Tim Wicinski  wrote:
> 
> 
> Thanks Eric
> 
> I'll review this (as I hope the other chairs will too), and we could get that
> rolling in the next few weeks.
> 
> tim
> 
> 
> On Fri, Jun 12, 2020 at 4:40 PM Erik Nygren  > wrote:
> As discussed in a previous thread, we've renamed the HTTPSSVC RR to be the 
> "HTTPS" RR.
> The SVCB RR is keeping its name.
> A new version of the draft has been published with this change as well as 
> with other changes:
> 
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ 
> 
> 
> (We separated the rename change out as a separate version from
> the other changes to make it easier to diff them separately.)
> 
> I think we're at the point now where it would be good to make a last
> call for feedback and inputs prior to asking for an early code point 
> allocation
> for the HTTPS RR and SVCB RR.
> 
>Erik
> 
> 
> 
> On Wed, Jun 10, 2020 at 7:00 PM Alessandro Ghedini  > wrote:
> Hello,
> 
> At the risk of re-opening a can of worms, there was a discussion a while ago 
> on
> this list on renaming the SVCB and HTTPSSVC records to something else
> https://mailarchive.ietf.org/arch/msg/dnsop/dh_H24_Dq-nr4TkO0FCqySjsnC8/ 
> 
> 
> So I was wondering where that discussion landed (if anywhere) as I can't seem 
> to
> be able to find any resolution to that on the list.
> 
> To be clear, I don't particularly care either way, but if a rename is going to
> happen I'd rather it happens sooner as it will affect implementers, and it 
> might
> unduly cause people to hold back from merging/deploying code in case a rename
> actually happens, e.g. 
> https://github.com/miekg/dns/pull/1067#issuecomment-627807069 
> 
> 
> Cheers
> 
> ___
> 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
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Tommy Pauly]

> On Feb 18, 2020, at 6:15 PM, Rob Sayre  wrote:
> 
> On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja  > wrote:
> 
> SVCB is active almost every day of the week in GitHub.
> 
> If someone wanted to follow this work, which GitHub repo is relevant?
> 
> I found this one: https://github.com/MikeBishop/dns-alt-svc 
> 
> 
> But I'm not sure that's the right one.

Yes, that is the correct GitHub.

Thanks,
Tommy
> 
> thanks,
> Rob
>  
> ___
> 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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Tommy Pauly]

+1 to the liveness of SVCB. As seen in the work on GitHub, there’s engagement 
from people working on ESNI and other use cases. I’ve been following the draft 
on GitHub and testing implementations, for example.

Tommy

> On Feb 18, 2020, at 10:07 AM, Eric Orth 
>  wrote:
> 
> Hasn't been discussed much lately on this list (I keep meaning to get back to 
> the chain-length discussion from a month or so back), but SVCB is definitely 
> very much still alive.  Lots of work is going on in its github to prepare the 
> next draft, so I assume we'll have another round of discussions here soon 
> whenever that is ready.
> 
> On Tue, Feb 18, 2020 at 11:17 AM Olli Vanhoja  > wrote:
> 
> On Tue, Feb 18, 2020, 16:20 Klaus Malorny  > wrote:
> 
> I asked myself about the status of the two drafts. I got the impression a 
> little 
> bit that the svcb/httpsvc draft successfully killed the aname draft, but is 
> now 
> dying slowly itself. It would be great if somebody could give me some insight 
> whether the one or the other has still a measurable heartbeat, to stay with 
> the 
> allegories ;-)
> 
> SVCB is active almost every day of the week in GitHub.
> 
> I can't talk on behalf of the authors of the ANAME draft, but to me it seems 
> that SVCB is getting more traction and it addresses the core problems that 
> ANAME was supposed to solve.
> 
> ___
> 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
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] On painting the draft-ietf-dnsop-svcb-httpssvc bikeshed

[Tommy Pauly]

Hello DNSOP,

In the interest of getting this spec ready to go, I want to start our bikeshed 
on the RRTYPE name. We need a stable name that we all can live with.

I'll start. Please chime in!

Since it seems that many people like SVCB, and many don't like HTTPSSVC (too 
many repeated SS's!), I suggest using:

SVCB (referred to as "Service Binding")

SVCB-HTTPS (referred to as"Service Binding for HTTPS")

Best,
Tommy___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc

[Tommy Pauly]

I support adoption of this document—although I agree that the names do need 
some bike shedding if/when it is adopted! This is a good mechanism to use for 
ESNI keys and Alt-Svc. I also think that the extensibility it provides is 
important property (for example, I am proposing to use it for designating 
encrypted DNS servers in 
https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy). 

I am also willing to contribute text and review the document.

Thanks,
Tommy

> On Oct 7, 2019, at 7:37 AM, Tim Wicinski  wrote:
> 
> 
> All
> 
> We want to thank the authors for working on this.  The chairs
> feel that part of the discussion around this document would be to
> resolve:
>   - ANAME/HTTPSSVC possible overlaps
>   - The RR Type Name (no one seems to be in love with current names)
> 
> This starts a Call for Adoption for draft-nygren-dnsop-svcb-httpssvc
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and 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: 21 October 2019
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> ___
> 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

Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Tommy Pauly]

> On Sep 24, 2019, at 6:17 AM, Erik Nygren  wrote:
> 
> Following discussions around the "HTTPSSVC" record proposal in Montreal with 
> the DNSOP, HTTP and TLS WGs, we've updated what was previously 
> "draft-nygren-httpbis-httpssvc-03".  The new version is 
> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the 
> feedback from the WG discussions, as well as feedback from discussions with 
> the TLS WG (as we'd like to see this replace the need for a separate ESNI 
> record).
> 
> In particular, it generalizes the record into a new "SVCB" record which 
> doesn't have any protocol-specific semantics.  It also defines an "HTTPSSVC" 
> record that is compatible with SVCB (sharing a wire-format and parameter 
> registry) and which defines the HTTP(S)-specific semantics such as bindings 
> to Alt-Svc.  Other protocols can either define bindings directly to SVCB or 
> can define their own RR Type (which should only ever be needed if there is a 
> need to use the record at a zone apex).
> 
> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs 
> can go against:  https://github.com/MikeBishop/dns-alt-svc 
> 
> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
> 
> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the 
> HTTPS-specific functionality and text to its own portion of the document).
> * Elimination of the SvcRecordType field (and making the SvcRecordType 
> implicit)
> * Changing the wire format of parameters from being in Alt-Svc text format to 
> a more general binary key/value pair format (with a mapping to Alt-Svc for 
> HTTPSSVC).
> * Adding optional "ipv4hint" and "ipv6hint" parameters.
> * Quite a few cleanups and clarifications based on input (and we undoubtedly 
> have more left to go)
> 
> This retains support for all of the use-cases that the previous HTTPSSVC 
> record had (such as for covering the ANAME / CNAME-at-the-zone-apex use-case).
> 
> Feedback is most welcome.  If the TLS WG is going to use this instead of a 
> separate ESNI record, there is a desire to make progress on this fairy 
> quickly.

I wanted to express support for getting this work adopted in DNSOP, and ideally 
doing so relatively soon so that we can unblock work on ESNI. From an OS 
implementor perspective, I'd really prefer to have an RR type that can be used 
for ESNI defined from DNSOP, and done so in a way (as this proposal does) that 
can be expanded to include other information like Alt-Svc, and even properties 
like support for DoH, etc.

I'd also ask that if this work is adopted, an early IANA allocation be made for 
the RR type once the basic record content and format is agreed upon.

Thanks to the authors for their work on this solution!

Best,
Tommy

> 
>Erik
> 
> -- Forwarded message -
> From: mailto:internet-dra...@ietf.org>>
> Date: Mon, Sep 23, 2019 at 7:01 PM
> Subject: New Version Notification for draft-nygren-dnsop-svcb-httpssvc-00.txt
> To: Mike Bishop mailto:mbis...@evequefou.be>>, Erik 
> Nygren mailto:erik%2bi...@nygren.org>>, Benjamin 
> Schwartz mailto:bem...@google.com>>
> 
> 
> 
> A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
> has been successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
> 
> Name:   draft-nygren-dnsop-svcb-httpssvc
> Revision:   00
> Title:  Service binding and parameter specification via the DNS (DNS 
> SVCB and HTTPSSVC)
> Document date:  2019-09-22
> Group:  Individual Submission
> Pages:  33
> URL:
> https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt 
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/ 
> 
> Htmlized:   
> https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 
> 
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc 
> 
> 
> 
> Abstract:
>This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
>types to facilitate the lookup of information needed to make
>connections for origin resources, such as for HTTPS URLs.  SVCB
>records allow an origin to be served from multiple network locations,
>each with associated parameters (such as transport protocol
>configuration and keying material for encrypting TLS SNI).  They also
>enable aliasing of apex domains, which is not possible with CNAME.
>The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP
>origins.  By providing more information to the client before it
>attempts to establish a connection, these records offer potential