Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.cloudflare.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=nNoSqGOSRERL8dkjB1QlOCBdkhp_1Yb6O4xqQcLg5E4&s=MkQQ3lsMEBID-6LoFx65__PgsMVCbXLT2Xp5Xxwb1l4&e=>
>  type65
>
> ; <<>> DiG 9.16.4-Debian <<>> blog.cloudflare.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.cloudflare.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=nNoSqGOSRERL8dkjB1QlOCBdkhp_1Yb6O4xqQcLg5E4&s=MkQQ3lsMEBID-6LoFx65__PgsMVCbXLT2Xp5Xxwb1l4&e=>
>  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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.cloudflare.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=nNoSqGOSRERL8dkjB1QlOCBdkhp_1Yb6O4xqQcLg5E4&s=MkQQ3lsMEBID-6LoFx65__PgsMVCbXLT2Xp5Xxwb1l4&e=>
> . IN TYPE65
>
> ;; ANSWER SECTION:
> blog.cloudflare.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.cloudflare.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=nNoSqGOSRERL8dkjB1QlOCBdkhp_1Yb6O4xqQcLg5E4&s=MkQQ3lsMEBID-6LoFx65__PgsMVCbXLT2Xp5Xxwb1l4&e=>
> . 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=
> <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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=nNoSqGOSRERL8dkjB1QlOCBdkhp_1Yb6O4xqQcLg5E4&s=80-OG9hSCfXT4Zbc93tA5Bd0FdLj0hAknhjLjvAfDww&e=>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>