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