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....@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....@dmarc.ietf.org> wrote: > > > > On Jul 22, 2020, at 5:46 PM, Wellington, Brian < > bwelling=40akamai....@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 <alessan...@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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
