Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

This is a case of reading a sentence out of context.

The first paragraph describing “mandatory” ends with:

The SvcParamKey "mandatory" is used to indicate any mandatory keys for this RR, in addition to any automatically mandatory keys that are present.

It also has:

In presentation format, "mandatory" contains a list of one or more valid SvcParamKeys,

I think there is already plenty of context to show that mandatory is optional.

> On 23 Jul 2020, at 11:31, Tim Wicinski <tjw.ietf@gmail.com> wrote:
> 
> Brian
> 
> I agree on clarity, and their git repo has been more recently updated. 
> I've been poking the authors on some better examples in the spec as well. 
> 
> https://github.com/MikeBishop/dns-alt-svc
> 
> 
> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian <bwelling=40akamai.com@dmarc.ietf.org> wrote:
> ok.  So, what this means is that keys listed in the “mandatory” parameter must be included as parameters, and are required to be understood by clients.  The set of “automatically mandatory” keys are required to be understood by clients, but are not required in the RR.
> 
> I’m a native English speaker, and have been working with DNS for over 20 years.  If I’m having trouble understanding this, perhaps the spec should be a bit clearer.
> 
> Brian
> 
>> On Jul 22, 2020, at 5:56 PM, Tommy Pauly <tpauly=40apple.com@dmarc..ietf.org> wrote:
>> 
>> 
>> 
>>> On Jul 22, 2020, at 5:46 PM, Wellington, Brian <bwelling=40akamai.com@dmarc.ietf.org> 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 <alessandro@ghedini.me> 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 000100000100150568332D32390568332D32380568332D3237026832 0004000868121A2E68121B2E00060020260647000000000000000000 68121A2E26064700000000000000000068121B2E
>>>> 
>>>> Cheers
>>>> 
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> DNSOP@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_dnsop&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=Ei0lUqjTt2OhRnRqJeO1XDCHQqnH1FdINDMcPEhCC1g&s=WQn55KFIZ5LGfsj-QGNSS31WGhpI-GuXpJEmhibwNuo&e= 
>>> 
>>> _______________________________________________
>>> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org