Subject: [DNSOP] SVCB proposals

From: Ben Schwartz <[email-masked]>
Date: Thu, 18 Feb 2021 10:36:55 -0500

The SVCB/HTTPS RR draft is nearing completion, but there are a few
remaining topics on which the authors would appreciate feedback from the
working group.  Personally, I've written up three proposed changes that
would benefit from broader input.  Please share your thoughts.

1. Change IANA policy to Specification Required
(https://github.com/MikeBishop/dns-alt-svc/pull/262/files)

The current proposed IANA policy for SvcParamKeys has allocatable ranges
under three different policies ("Standards Action", "Expert Review",
and "First Come First Served").  This is very flexible and enables
experimentation, but creates compatibility risk: a FCFS SvcParamKey could
be allocated without a clear specification of its zone file syntax, leading
to zone file portability issues.

This proposal would replace all these ranges with a uniform Specification
Required policy.  The required documentation is minimal: it is only
required to describe the zone file format.

2. Skip the default port prefix
(https://github.com/MikeBishop/dns-alt-svc/pull/230/files)

Using SVCB with a new protocol requires the initial QNAME to end with
_(scheme).$HOSTNAME.  The current text suggests (non-normatively) to add
_$PORT for endpoints that are identified by a port number.  This turns out
to be inelegant for protocols that almost always use the default port.  For
example, in the DNS mapping (draft-schwartz-svcb-dns), this would
correspond to names like "_53._dns.resolver.example".

This proposal would change the guidance to skip the port prefix when
starting with the default port (like "_dns.resolver.example").

3. Add a SHOULD-level chain length limit for zone owners
https://github.com/MikeBishop/dns-alt-svc/pull/294/files

Constructing huge chains of CNAME and AliasMode records is clearly a bad
idea, but how huge is too huge?  This change suggests not to use more than
8.  This doesn't change the requirements for resolvers (which are free to
impose any limit greater than zero) but it might help us to converge on
common behavior.

--Ben Schwartz

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 18 Feb 2021 09:11:49 -0800

Hi Ben,

Thanks for the work on the SVCB draft! It’s in really good shape, in my opinion. I’ve commented on these three PRs, but I’ll share my thoughts here as well.

> On Feb 18, 2021, at 7:36 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> The SVCB/HTTPS RR draft is nearing completion, but there are a few remaining topics on which the authors would appreciate feedback from the working group.  Personally, I've written up three proposed changes that would benefit from broader input.  Please share your thoughts.
> 
> (https://github.com/MikeBishop/dns-alt-svc/pull/262/files <https://github.com/MikeBishop/dns-alt-svc/pull/262/files>)
> 
> The current proposed IANA policy for SvcParamKeys has allocatable ranges under three different policies ("Standards Action", "Expert Review", and "First Come First Served").  This is very flexible and enables experimentation, but creates compatibility risk: a FCFS SvcParamKey could be allocated without a clear specification of its zone file syntax, leading to zone file portability issues.
> 
> This proposal would replace all these ranges with a uniform Specification Required policy.  The required documentation is minimal: it is only required to describe the zone file format.

I disagree with the rationale behind this change. I totally agree that we should have a clear zone file syntax, but based on RFC 8126 that defines the various buckets, FCFS registrations can have requirements for well-formatted entries with registry-specific requirements. We can mandate that the registration have a clear zone file syntax, without needing to be Specification Required. Specification Required requires expert review and is a heavier-weight process than what we necessarily need for an experimental range. 

The documentation that’s needed is minimal: the value, the name, and the zone file format. These can be entries directly in the registry, and will make the registry a more useful resource.

> (https://github.com/MikeBishop/dns-alt-svc/pull/230/files <https://github.com/MikeBishop/dns-alt-svc/pull/230/files>)
> 
> Using SVCB with a new protocol requires the initial QNAME to end with _(scheme).$HOSTNAME.  The current text suggests (non-normatively) to add _$PORT for endpoints that are identified by a port number.  This turns out to be inelegant for protocols that almost always use the default port.  For example, in the DNS mapping (draft-schwartz-svcb-dns), this would correspond to names like "_53._dns.resolver.example".
> 
> This proposal would change the guidance to skip the port prefix when starting with the default port (like "_dns.resolver.example").

This is a good change. Ship it!

> https://github.com/MikeBishop/dns-alt-svc/pull/294/files <https://github.com/MikeBishop/dns-alt-svc/pull/294/files>
> 
> Constructing huge chains of CNAME and AliasMode records is clearly a bad idea, but how huge is too huge?  This change suggests not to use more than 8.  This doesn't change the requirements for resolvers (which are free to impose any limit greater than zero) but it might help us to converge on common behavior.

This seems like a sensible change. I think the recommendation could be less that 8, but it shouldn’t be more. Leaving this at 8 seems fine.

Best,
Tommy
> 
> --Ben Schwartz
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 18 Feb 2021 13:19:23 -0500

On Thu, Feb 18, 2021 at 12:11 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hi Ben,
>
> Thanks for the work on the SVCB draft! It’s in really good shape, in my
> opinion. I’ve commented on these three PRs, but I’ll share my thoughts here
> as well.
>
> On Feb 18, 2021, at 7:36 AM, Ben Schwartz <
> bemasc=[email-masked]> wrote:
>
> I disagree with the rationale behind this change. I totally agree that we
> should have a clear zone file syntax, but based on RFC 8126 that defines
> the various buckets, FCFS registrations can have requirements for
> well-formatted entries with registry-specific requirements. We can mandate
> that the registration have a clear zone file syntax, without needing to
> be Specification Required. Specification Required requires expert review
> and is a heavier-weight process than what we necessarily need for an
> experimental range.
>
> The documentation that’s needed is minimal: the value, the name, and the
> zone file format. These can be entries directly in the registry, and will
> make the registry a more useful resource.
>

To be precise, the specification must explain how to convert from zone file
format to wire format.  In some cases, this could be very simple, but I
wonder if even trivial cases are compact enough to encode _inside_ an IANA
registry entry.  Do you know of any registry that is structured this way
today?

Also, using a registration policy of First Come First Served, where one of
the required attributes is a specification, seems like an end-run around
IANA's standard procedures for no clear reason.

I would appreciate input from anyone with more IANA experience on how this
ought to work.  I think we largely have agreement on the intended policy
here, and are looking for the right way to encode it as an IANA
instruction.  In particular, I think we should make it very easy to define
new SvcParamKeys that reuse the presentation format of an existing
SvcParamKey.

I note that there are several older registries (e.g. [1],[2]) whose policy
is given as "First Come First Served with specification" or similar,
despite no such option being listed in RFC 8126 or its predecessors.
(Notably, many of the entries in [1] appear to lack such a specification,
despite the registry's documented policy.)

[1]
https://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-parameters-47
[2]
https://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml#ldap-parameters-8