Subject: [DNSOP] HTTPS/SVCB on Cloudflare DNS

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 16 Jul 2020 16:13:56 +0100

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Jul 2020 01:37:35 +1000

Do you have a estimate on when you will enable additional section processing for these records?

> On 17 Jul 2020, at 01:13, Alessandro Ghedini <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 16 Jul 2020 18:26:04 +0100

> Do you have a estimate on when you will enable additional section processing for these records?

Not sure I understand the question. Do you mean authoritative servers adding
A/AAAA records to additional section of HTTPS responses?

Cheers

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Jul 2020 10:11:33 +1000

> On 17 Jul 2020, at 03:26, Alessandro Ghedini <[email-masked]> wrote:
> 

Yes.  At the moment there will be lots of redundant queries being made. A, AAAA
and HTTPS/SVBC for every level of the chain. If HTTPS/SVBC aware servers actually
return A and AAAA records for service form records, we can reduce the number of
queries that need to be made.

We need to get to the state where HTTPS/SVBC alias form always reaches a HTTPS/SVBC
service form.  When we are mostly in that state we can stop doing A and AAAA queries
along side the HTTPS/SVBC query for names in the HTTPS/SVBC alias form and take the
RTT hit on the occasional NODATA response.  To get to that state we need the DNS
servers of the content providers to be HTTPS/SVBC aware and to populate the additional
section whenever possible.

BIND’s HTTPS/SVBC implementation adds A, AAAA, CNAME, and HTTPS/SVBC records and
looks for them in the response.  I would expect all HTTPS/SVBC aware clients to
look for these records in the response.  At the moment we don’t look for DNAME in
the additional section nor do we add it because, quite frankly, they should not be
there in any sensible deployment.  DNAME in the answer section is expected.

Mark

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 22 Jul 2020 15:29:50 -0400

Alessandro

Thanks for letting us know about this.

But to follow up on what Mark says. If Cloudflare isn't planning on
returning them, I'd like to understand the reasons why.

tim

On Thu, Jul 16, 2020 at 8:12 PM Mark Andrews <[email-masked]> wrote:

> >>> blog.cloudflare.com.        300     IN      TYPE65  \# 76
> 000100000100150568332D32390568332D32380568332D3237026832
> 0004000868121A2E68121B2E00060020260647000000000000000000
> 68121A2E26064700000000000000000068121B2E
> >>>
> >>> Cheers
> >>>

---

From: "Wellington, Brian" <[email-masked]>
Date: Thu, 23 Jul 2020 00:46:44 +0000

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?

Thanks,
Brian

> On Jul 16, 2020, at 8:13 AM, Alessandro Ghedini <[email-masked]> wrote:
> 
> Hello,
> 
> 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=

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Jul 2020 17:56:27 -0700

> On Jul 22, 2020, at 5:46 PM, Wellington, Brian <bwelling=[email-masked]> wrote:
> 

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 <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello,
>> 
>> 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=> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2020 10:59:10 +1000

> On 23 Jul 2020, at 10:46, Wellington, Brian <bwelling=[email-masked]> wrote:
> 

Please read the entire sentence.  "This SvcParamKey is always automatically mandatory, and MUST NOT appear in its own value list.”  It’s saying if “mandatory" is there you must process the record as if it starts with “mandatory=mandatory,” but the value of 0 MUST NOT be included in the list.

---

From: "Wellington, Brian" <[email-masked]>
Date: Thu, 23 Jul 2020 01:19:48 +0000

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=[email-masked]<mailto:tpauly=[email-masked]>> wrote:

On Jul 22, 2020, at 5:46 PM, Wellington, Brian <bwelling=[email-masked]<mailto:bwelling=[email-masked]>> wrote:

Thanks,
Tommy

Thanks,
Brian

On Jul 16, 2020, at 8:13 AM, Alessandro Ghedini <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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=>

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 22 Jul 2020 21:31:34 -0400

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=
[email-masked]> 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=[email-masked]> wrote:
>
>
>
> On Jul 22, 2020, at 5:46 PM, Wellington, Brian <
> bwelling=[email-masked]> 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.
>
>
> 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:
>
> 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 “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
>
>  % 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:
> ;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
> 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=>
>
>
>
> <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=>
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 22 Jul 2020 21:41:15 -0400

>From the client's perspective, "mandatory" means "if you don't understand
all of these keys, discard the RR".  Each key on the list is "mandatory" in
the sense that it conveys information that is required to make correct use
of the RR.  All other keys are optional: they can be ignored and the RR
will still "work" for connection establishment.

"Automatically mandatory" means "this key is mandatory if it is present".

If you can think of a clearer presentation, please send text!

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2020 11:45:44 +1000

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 <[email-masked]> wrote:
> 
> Brian
> 
> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian <bwelling=[email-masked]> wrote:
>> On Jul 22, 2020, at 5:56 PM, Tommy Pauly <tpauly=40apple.com@dmarc..ietf.org> wrote:
>> 
>> 
>> 
>>>> ;blog.cloudflare.com.
>>>> IN
>>>> TYPE65
>>>> blog.cloudflare.com.
>>>> 300 IN
>>>> TYPE65 \# 76 000100000100150568332D32390568332D32380568332D3237026832 0004000868121A2E68121B2E00060020260647000000000000000000 68121A2E26064700000000000000000068121B2E
>>>> 
>>>> Cheers
>>>>

---

From: "Wellington, Brian" <[email-masked]>
Date: Thu, 23 Jul 2020 01:47:42 +0000

If your interpretation of this comes down to “mandatory is optional”, then that shows how confusing this is.

Brian

> On Jul 22, 2020, at 6:45 PM, Mark Andrews <[email-masked]> wrote:
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_MikeBishop_dns-2Dalt-2Dsvc&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=NAnMW9xGWQVnYnS9I88YowKyWxHMrEM3ACuElx9IB5Y&e= 
>> 
>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=T4xEg4ZgSU98oALn8LAXlkcHcJsPFbcGLuBwIOLAef0&e= 
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=T4xEg4ZgSU98oALn8LAXlkcHcJsPFbcGLuBwIOLAef0&e= 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=T4xEg4ZgSU98oALn8LAXlkcHcJsPFbcGLuBwIOLAef0&e= 
> 
> -- 
> Mark Andrews, ISC

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2020 12:09:18 +1000

mandatory is described thus:

"In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not 
function correctly for clients that ignore this SvcParamKey. Each SVCB protocol
mapping SHOULD specify a set of keys that are "automatically mandatory", i.e. 
mandatory if they are present in an RR. The SvcParamKey "mandatory" is used to 
indicate any mandatory keys for this RR, in addition to any automatically 
mandatory keys that are present.

A ServiceMode RR is considered "compatible" with a client if the client implements 
support for all its mandatory keys. If the SVCB RRSet contains no compatible RRs, 
the client will generally act as if the RRSet is empty.

In presentation format, "mandatory" contains a list of one or more valid SvcParamKeys, 
either by their registered name or in the unknown-key format ({{presentation}}). Keys 
MAY appear in any order, but MUST NOT appear more than once. Any listed keys MUST also 
appear in the SvcParams. To enable simpler parsing, this SvcParam MUST NOT contain 
escape sequences.

For example, the following is a valid list of SvcParams:

echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig

In wire format, the keys are represented by their numeric values in network byte order, 
concatenated in ascending order.

This SvcParamKey is always automatically mandatory, and MUST NOT appear in its own 
value list. Other automatically mandatory keys SHOULD NOT appear in the list either. 
(Including them wastes space and otherwise has no effect.)”

I don’t see how, after reading that, one can conclude that all ServiceMode records
MUST include the key “mandatory”.

Mark

> On 23 Jul 2020, at 11:47, Wellington, Brian <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2020 12:12:08 +1000

We could change the sentence to start with "This SvcParamKey MUST NOT be ignored,"

> On 23 Jul 2020, at 12:09, Mark Andrews <[email-masked]> wrote:
>

---

From: "Wellington, Brian" <[email-masked]>
Date: Thu, 23 Jul 2020 02:38:20 +0000

Because the definitions of “mandatory” and “automatically mandatory” are not all that clear.  And “mandatory” is also a word in the English language, with meanings and connotations (and is the opposite of “optional”). 

The spec is internally consistent, but it definitely could be made be more clear.

Brian

> On Jul 22, 2020, at 7:12 PM, Mark Andrews <[email-masked]> wrote:
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=FtMnEZFyfLXTvyM7ZAFq08FBW1-7qUZvzg_tT0X3PQE&s=cmmQysWJ2dW9RAvBo6_GULomfiLuXTV1dl-FlMQDTEI&e= 
> 
> -- 
> Mark Andrews, ISC

---

From: Petr Špaček <[email-masked]>
Date: Thu, 23 Jul 2020 08:51:36 +0200

On 23. 07. 20 3:41, Ben Schwartz wrote:
> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian <bwelling=[email-masked] <mailto:[email-masked]>> wrote:
> 
> From the client's perspective, "mandatory" means "if you don't understand all of these keys, discard the RR".  Each key on the list is "mandatory" in the sense that it conveys information that is required to make correct use of the RR.  All other keys are optional: they can be ignored and the RR will still "work" for connection establishment.
> 

I'm not native English speaker and I personally find confusing that sequence of characters "mandatory" is used as verb and also as name of the key. "optional mandatory" sounds like a joke.

To clarify this I propose to rename "mandatory" field to "critical", which terminologically aligns with X.509 and also LDAP.

-- 
Petr Špaček  @  CZ.NIC

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2020 17:33:03 +1000

> On 23 Jul 2020, at 16:51, Petr Špaček <[email-masked]> wrote:
> 

Please don’t change field names.  Master files are interchange documents (see STD13) and the presentation format is theoretically fixed when the type code is allocated.

Mark

---

From: Dick Franks <[email-masked]>
Date: Thu, 23 Jul 2020 09:40:12 +0100

On Thu, 23 Jul 2020 at 08:33, Mark Andrews <[email-masked]> wrote:

 >8

>
> > I'm not native English speaker and I personally find confusing that
> sequence of characters "mandatory" is used as verb and also as name of the
> key. "optional mandatory" sounds like a joke.
>
s/verb/adjective/

>
> > To clarify this I propose to rename "mandatory" field to "critical",
> which terminologically aligns with X.509 and also LDAP.
>
> Please don’t change field names.  Master files are interchange documents
> (see STD13) and the presentation format is theoretically fixed when the
> type code is allocated.
>

+1

Apart from "mandatory" itself, which cannot avoid being mandatory, what
distinguishes an "automatically mandatory" key from any other optional key
not listed in key0?

If there is no distinction, why persist with this "automatically mandatory"
nonsense.

--Dick

---

From: Brian Dickson <[email-masked]>
Date: Thu, 23 Jul 2020 02:34:59 -0700

> If you can think of a clearer presentation, please send text!

Definitions to use:
Required: Must be present, and implies Mandatory to Implement. (Having a
Required element that wasn't MTI would be silly.)
Mandatory to Implement: exactly what it says.
Optional: Neither Required nor MTI.

Mandatory should only ever be used as MTI, otherwise it leads to confusion
(i.e. needing subordinate phrase to disambiguate, e.g. mandatory to
implement vs mandatory to include.)

Then have a table of key names, and which kind they are (Req, MTI, Opt).

That should clear it up, I think.

Brian

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 23 Jul 2020 10:50:40 +0100

> queries that need to be made.

I did a little experiment (took me a few days to find the time) with a toy DNS
server [0]. This is obviously not a proper authoritative server, it's just to
illustrate the problem.

When I query the auth server directly I get the HTTPS response as well as the
additional section records:

     % dig @ns1.nullroute.dev nullroute.dev. type65

    ; <<>> DiG 9.16.4-Debian <<>> @ns1.nullroute.dev nullroute.dev. type65
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18948
    ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available

    ;; QUESTION SECTION:
    ;nullroute.dev.			IN	TYPE65

    ;; ANSWER SECTION:
    nullroute.dev.		300	IN	TYPE65	\# 21 00010000010006026832026833000400042D4D6042

    ;; ADDITIONAL SECTION:
    nullroute.dev.		300	IN	A	198.51.100.1

But if I go through a resolver the additional section seems to be stripped:

     % dig @8.8.8.8 nullroute.dev. type65 

    ; <<>> DiG 9.16.4-Debian <<>> @8.8.8.8 nullroute.dev. type65
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62418
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;nullroute.dev.			IN	TYPE65

    ;; ANSWER SECTION:
    nullroute.dev.		299	IN	TYPE65	\# 21 00010000010006026832026833000400042D4D6042

I tried a few other public resolvers and I see the same. If this is the actual
behavior of resolvers (rather than just an artifact of my experiment's setup)
then adding additional section wouldn't seem to provide much benefit for
"end-user" clients (say, a browser).

Is the expectation that additional section would help resolvers reduce the
number of queries rather than the other DNS clients? I guess other clients would
still need to query A/AAAA and HTTPS in parallel as they don't know whether
there is an HTTPS record at all.

In any case we don't have plans right now to implement this on Cloudflare's DNS
servers, but it's certainly possible. I will discuss this with our DNS people
and see what they think.

Cheers

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 23 Jul 2020 10:57:29 +0100

> servers, but it's certainly possible. I will discuss this with our DNS people

Also btw, currently we always include ipv4hint and ipv6hint in our HTTPS
responses, this is to avoid breaking connections in multi-CDN scenarios, so I
guess a resolver could in theory use this information instead? The draft is, I
believe, a tad too strict regarding the usage of hints, so I'm not sure if this
is forbidden or not.

Cheers

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 23 Jul 2020 11:12:00 +0100

On Thu, Jul 23, 2020 at 10:50:40AM +0100, Alessandro Ghedini wrote:
> server [0].

Forgot to add the link here. The "[0]" was supposed to point to:
https://gist.github.com/ghedo/cdb98af5df6a8a2bf97aac6a06ab27aa

> This is obviously not a proper authoritative server, it's just to
> illustrate the problem.
>

---

From: Jared Mauch <[email-masked]>
Date: Thu, 23 Jul 2020 07:52:53 -0400

Exactly. Mandatory is required except when it's not. I'll think of some improved text. 

Sent from my iCar

> On Jul 22, 2020, at 10:09 PM, Mark Andrews <[email-masked]> wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 23 Jul 2020 10:22:00 -0400

> distinguishes an "automatically mandatory" key from any other optional key

Consider "port".  This key is "automatically mandatory" for HTTPS, because
a client who ignores the "port" key will not be able to connect using an RR
that contains the "port" key.  (They would connect to the wrong port.)

In contrast, consider "echconfig".  This key is a normal, optional key
(unless listed in "mandatory"), because ECH is an optional extension to
TLS, so clients who ignore "echconfig" can still connect using RRs that
contain an "echconfig" SvcParam.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 23 Jul 2020 10:31:50 -0400

On Thu, Jul 23, 2020 at 5:57 AM Alessandro Ghedini <[email-masked]>
wrote:

> responses, this is to avoid breaking connections in multi-CDN scenarios,

Note that this is not guaranteed to work.  A client who has the other CDN's
AAAA record in cache will ignore your ipv6hint, leading to ECH failure.
The proper way to support this is to make sure that TargetName is never a
multi-CDN name.

The advice in previous drafts was arguably confusing on this point.  The
latest draft updates the "Structuring Zones for Performance" section in an
attempt to clarify:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-5.3

so I
> believe, a tad too strict regarding the usage of hints, so I'm not sure if

I'm not sure what you're proposing, but recursive resolvers are certainly
forbidden from synthesizing address records based on the ipv*hints.
However, the ipv*hints do allow clients to connect without waiting for
followup queries if they don't get address records in the Additional
section, which should address the performance question in this case.

Cheers
> > > >> PHONE: +61 2 9871 4742 <+61%202%209871%204742>
> INTERNET: [email-masked]
> > > >>
> > >
> > > --
> > > Mark Andrews, ISC
> > > PHONE: +61 2 9871 4742 <+61%202%209871%204742>              INTERNET:
> [email-masked]
> > >
> >

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Jul 2020 01:20:41 +1000

> On 23 Jul 2020, at 19:50, Alessandro Ghedini <[email-masked]> wrote:
> 

I’m trying to determine if you are serious here.  Did you honestly expect recursive
servers that know about HTTPS and SVBC, had hence have code to add the addition section
records to the response, to have been deployed in the 3 weeks since the type codes
have been assigned?  Especially so when parameters like “mandatory” have only appeared
in the latest draft on July 13?  Add to that these records have significantly different
additional section processing to any other type.  It’s not just lookup the type by name
and add it to the additional section which.  It adding CNAMEs, which no other record
requires, and loop prevention code as well. It’s protecting against effectively infinite
chains.

It’s also adding code to detect and these records in responses and decide if they are
appropriate.  Again the rules for doing this differ in design from any other deployed
type.

You can add to all of this, a sense that the records are still not stable and really
should not have had type codes assigned when they where.  There was no stable reference
for “mandatory” when they where assigned.  IANA references draft-ietf-dnsop-svcb-https-00
which doesn’t contain “mandatory”.  The draft was, and potentially still is, not stable
enough for permanent code points.  I’m just hoping that we don’t get into serious
interoperability issues between implementations because of this.  A -00 server can accept
but not verify a record produced by a -01 server over the wire.  A -00 server can’t accept
all records, in presentation form, produced by -01 sources.  Do -01 sources now have to
emit ‘key0=“…”’ for mandatory to work around this incompatibility?  I suspect not as any
-00 servers will be replaced, but there is alway the possibility that someone will come
along and implement HTTPS and SVCB against -00 assuming that the description of the
records there is complete enough (which it clearly isn’t).

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 23 Jul 2020 17:43:31 +0100

On Fri, Jul 24, 2020 at 01:20:41AM +1000, Mark Andrews wrote:
> I’m trying to determine if you are serious here.

Yes, I was serious.

> Did you honestly expect recursive servers that know about HTTPS and SVBC, had
> hence have code to add the addition section records to the response, to have
> been deployed in the 3 weeks since the type codes have been assigned?

No, that's not at all what I was expecting. I was just trying to figure who this
would benefit since it wasn't completely clear to me from your email, and I
wasn't previously aware of the resolvers behaviour regarding additional section
(TIL I guess).

Maybe I wasn't clear either, but In my email I asked:

    Is the expectation that additional section would help resolvers reduce the
    number of queries rather than the other DNS clients?

Reading between the lines, your reply seems to confirm that indeed what you are
expecting is that it would help resolver.

Cheers

> Especially so when parameters like “mandatory” have only appeared

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 23 Jul 2020 17:45:29 +0100

> forbidden from synthesizing address records based on the ipv*hints.

Yeah, you are right I realized this didn't make sense just after sending the
email.

Cheers

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Jul 2020 09:23:06 +1000

> On 24 Jul 2020, at 02:43, Alessandro Ghedini <[email-masked]> wrote:
> 

The benefit comes when the chains look like this with possible CNAMEs in the middle.

HTTPS (alias form) -> HTTPS (Service form) -> Addresses

It’s not the first lookup that sees the benefit at this time.  It would be nice if
we get to the stage where we are with SMTP that almost all delivery domains there is
a MX record.  That takes education to fix for HTTPS.  For new services its just a
matter of says SVCB is SHOULD.  

The alias to service form lookups is where you should see the benefit. 

Note recursive servers can prefetch on cache misses for additional data and even
stall the response to fill up the additional section.  The following is a experimental
branch for BIND 9 that does that for SRV.

https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/449

There is nothing that actually prevents recursive servers vendors shipping code like this
which knows about HTTPS and SVCB.  Now that merge request and the HTTPS/SVCB merge request
handle CNAMEs slightly differently so I don’t intend to merge that as is but parts of that
are quite likely to make it into future version of BIND.

There does have to be limits on the amount of prefetching a single query can trigger however
so that is doesn’t get weaponised.  Doing A and AAAA prefetches on HTTPS alias form targets
need to not be needed.