Subject: [DNSOP] SVCB and the specialness of _

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Oct 2020 19:51:59 -0400

Hi DNSOP,

There was recently an interesting proposal [1] for a change to the SVCB
draft that seems to merit input from the working group.

Background:
When using SVCB, clients append an underscore prefix ("Attrleaf") to the
name, containing the "scheme".  When there is an actual URI involved this
will literally be the URI scheme, e.g. _ftp.ftp.example.net.  Schemes can
prepend additional underscore-prefix labels to encode scheme-specific
service identifiers; the only anticipated use for this is a port number
(e.g. _8080._https.www.example.com).

SVCB also contains a small optimization: In ServiceMode, if the TargetName
is ".", this means "use the address records for the owner name".  This
reduces packet size (since name compression is not possible in new RR
types), but more importantly, it makes zone file editing easier and guides
zone owners toward the "happy path", where there is no latency penalty
because the resolver has already requested the corresponding address
records.

This construction works well for HTTPS on port 443, and for any lookup
following an AliasMode record, because in those cases the SVCB/HTTPS, A,
and AAAA queries all share the same QNAME.  However, it does not work when
the initial query has underscore labels and returns a ServiceMode record,
because the ServiceMode record's name is not the hostname (due to the
underscore labels).

Proposal:
The proposal would change the meaning of "." from "Use the SVCB record's
owner name" to "Use the SVCB record's owner name *minus any leading
underscore labels*".

Pro: TargetName = "." would now coincide with the "happy path" in all
ordinary cases.
* Simpler guidance to zone owners (always prefer ".")
* Clearer design rationale ("." is where the address queries already went)
* Shorter RDATA in the "happy path" case (for some non-HTTPS uses)

Con:
* Servers (recursive and authoritative) that perform Additional Section
processing would have to implement this underscore-label stripping
procedure.  This would be a rare violation of DNS's usual abstraction
barrier (servers don't normally discriminate based on the format of labels).
* There could be a change of operational control (e.g. zone cut or CNAME)
between _port._scheme.$HOSTNAME and $HOSTNAME, in which case the
ServiceMode record might actually prefer to use address records at its own
name, despite the latency cost.
* This gets very tricky if an AliasMode or CNAME target contains underscore
prefixes.  It may be impossible to stay on the "happy path" in all these
cases.

[1] https://github.com/MikeBishop/dns-alt-svc/issues/252

---

From: Brian Dickson <[email-masked]>
Date: Tue, 6 Oct 2020 17:51:33 -0700

On Tue, Oct 6, 2020 at 4:52 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> * This gets very tricky if an AliasMode or CNAME target contains
> underscore prefixes.  It may be impossible to stay on the "happy path" in
> all these cases.
>

(Apologies for not scattering comments in-line above, however, doing so may
detract from the context for the comments.)

Other than the syntactic brevity, is there any functional difference to the
client between a TargetName of "." versus a TargetName of "$HOSTNAME" in
the description above?

I'm not a huge fan of making RDATA special casing exclusively for zone
editing convenience. I think the RDATA size argument is not something that
should hold much (or any) weight, IMNSHO.

There are perhaps other ways of achieving the same goals, with more-or-less
the same level of user guidance and simplicity, in the zone file editing
function.

First, is the use of the standard zone file construct of "@", which only
exists within the zone master file, and gets substituted on import with
whatever $ORIGIN is.

Second, is the use of DomainConnect templates, which allow service
providers (such as CDNs or hosting companies) to provide templates for end
users (registrants) that are used by DNS providers to populate fields
automatically.
In the DomainConnect world, the template is managed by the service
provider, not the user, and removes most of the difficulty from managing
common DNS records.

(Non-sequitur: I am intending to pick up the IETF drafts for
domainconnect and update them, and try to get them adopted and published.)

I think both of these alternative techniques would be effective, and would
not have the problems listed in the "Con" section above.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Oct 2020 21:09:50 -0400

On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <[email-masked]>
wrote:

>
> Other than the syntactic brevity, is there any functional difference to
> the client between a TargetName of "." versus a TargetName of "$HOSTNAME"
> in the description above?
>

Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are
applied).  With the proposed change, "." would always mean $HOSTNAME when a
ServiceMode record is returned directly for the original query.  However,
if the ServiceMode record is reached via a CNAME or AliasMode record, then
"." does not correspond to (the original) $HOSTNAME.

> exists within the zone master file, and gets substituted on import with

Yes, the syntax already supports "@" and relative names when writing out a
TargetName in the zone file.  This is useful, but I don't think it has the
effect of guiding users toward a good configuration.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Oct 2020 06:23:34 -0700

This change seems reasonable, and makes “.” still more useful for the generic SVCB case.

Thanks,
Tommy

> On Oct 6, 2020, at 4:51 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> Hi DNSOP,
> 
> There was recently an interesting proposal [1] for a change to the SVCB draft that seems to merit input from the working group.
> 
> Background:
> When using SVCB, clients append an underscore prefix ("Attrleaf") to the name, containing the "scheme".  When there is an actual URI involved this will literally be the URI scheme, e.g. _ftp.ftp.example.net <http://ftp.ftp.example.net/>.  Schemes can prepend additional underscore-prefix labels to encode scheme-specific service identifiers; the only anticipated use for this is a port number (e.g. _8080._https.www.example.com <http://https.www.example.com/>).
> 
> SVCB also contains a small optimization: In ServiceMode, if the TargetName is ".", this means "use the address records for the owner name".  This reduces packet size (since name compression is not possible in new RR types), but more importantly, it makes zone file editing easier and guides zone owners toward the "happy path", where there is no latency penalty because the resolver has already requested the corresponding address records.
> 
> This construction works well for HTTPS on port 443, and for any lookup following an AliasMode record, because in those cases the SVCB/HTTPS, A, and AAAA queries all share the same QNAME.  However, it does not work when the initial query has underscore labels and returns a ServiceMode record, because the ServiceMode record's name is not the hostname (due to the underscore labels).
> 
> Proposal:
> The proposal would change the meaning of "." from "Use the SVCB record's owner name" to "Use the SVCB record's owner name *minus any leading underscore labels*".
> 
> Pro: TargetName = "." would now coincide with the "happy path" in all ordinary cases.
> * Servers (recursive and authoritative) that perform Additional Section processing would have to implement this underscore-label stripping procedure.  This would be a rare violation of DNS's usual abstraction barrier (servers don't normally discriminate based on the format of labels).
> * There could be a change of operational control (e.g. zone cut or CNAME) between _port._scheme.$HOSTNAME and $HOSTNAME, in which case the ServiceMode record might actually prefer to use address records at its own name, despite the latency cost.
> * This gets very tricky if an AliasMode or CNAME target contains underscore prefixes.  It may be impossible to stay on the "happy path" in all these cases.
> 
> [1] https://github.com/MikeBishop/dns-alt-svc/issues/252 <https://github.com/MikeBishop/dns-alt-svc/issues/252>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Brian Dickson <[email-masked]>
Date: Wed, 7 Oct 2020 12:20:29 -0700

On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz <[email-masked]> wrote:

> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <
> [email-masked]> wrote:
>
>>

This presents two significant problems.

First, this (what you write above) means that "." will not be guaranteed
100% of the time to result in the "correct" value, if I understand
correctly.

Second, the use of "." by whoever creates the ServiceMode record may not be
aware of how it is reached (e.g. by CNAME or AliasMode records not under
their control or that they are aware of or which may be added later).

Unless I misunderstand, I think the lack of 100% correctness in all
scenarios means this will cause difficult-to-find-and-fix operational
problems.

For this reason, I strongly suggest removing the "." and its special
handling.

As you note below, "@" is available, and while perhaps not as elegant, is
handled in the authority server's loading of zone files, and never results
in dynamic processing or additional handling requirements. I.e. it achieves
maybe 90% of the intended "happy" result, but does so with 100%
interoperability after the zone itself is constructed and loaded.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 7 Oct 2020 15:26:56 -0400

> 100% of the time to result in the "correct" value, if I understand

I'm not sure what you mean by "correct".  With or without this proposal,
the expanded name for "." is well-defined.

> their control or that they are aware of or which may be added later).

The expanded name does not depend on how the record was reached.  I'm
merely trying to point out that, after an alias has been followed, any
information about "$HOSTNAME" has been lost.

...

> interoperability after the zone itself is constructed and loaded.

My impression is that "@" is always, or nearly always, a zone apex.  I
expect that the majority of HTTPS and SVCB records will not be for the zone
apex.  Setting a ServiceMode TargetName of @ would instruct those records
to use the A/AAAA records for the apex name.  This strikes me as an
unlikely configuration.

>> Yes, the syntax already supports "@" and relative names when writing out
>> a TargetName in the zone file.  This is useful, but I don't think it has
>> the effect of guiding users toward a good configuration.
>>
>
> Brian
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Oct 2020 14:11:08 -0700

> On Oct 7, 2020, at 12:26 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Other than the syntactic brevity, is there any functional difference to the client between a TargetName of "." versus a TargetName of "$HOSTNAME" in the description above?
> 
> Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are applied).  With the proposed change, "." would always mean $HOSTNAME when a ServiceMode record is returned directly for the original query.  However, if the ServiceMode record is reached via a CNAME or AliasMode record, then "." does not correspond to (the original) $HOSTNAME.
> 
> First, this (what you write above) means that "." will not be guaranteed 100% of the time to result in the "correct" value, if I understand correctly.
> 
> I'm not sure what you mean by "correct".  With or without this proposal, the expanded name for "." is well-defined.
> 
> Second, the use of "." by whoever creates the ServiceMode record may not be aware of how it is reached (e.g. by CNAME or AliasMode records not under their control or that they are aware of or which may be added later).
> 
> The expanded name does not depend on how the record was reached.  I'm merely trying to point out that, after an alias has been followed, any information about "$HOSTNAME" has been lost.

+1. The “.” is very clear in meaning, since it is only referring to a name that is in the record itself. It’s not about where the chain comes from. This proposal is only about cleaning up a case where that name in the record has less helpful “_foo" prefixes. We absolutely should keep the “.” meaning as-is for all other cases.

Tommy

> 
> ...
> As you note below, "@" is available, and while perhaps not as elegant, is handled in the authority server's loading of zone files, and never results in dynamic processing or additional handling requirements. I.e. it achieves maybe 90% of the intended "happy" result, but does so with 100% interoperability after the zone itself is constructed and loaded.
> 
> My impression is that "@" is always, or nearly always, a zone apex.  I expect that the majority of HTTPS and SVCB records will not be for the zone apex.  Setting a ServiceMode TargetName of @ would instruct those records to use the A/AAAA records for the apex name.  This strikes me as an unlikely configuration.
> 
>  
> 
> First, is the use of the standard zone file construct of "@", which only exists within the zone master file, and gets substituted on import with whatever $ORIGIN is.
> 
> Yes, the syntax already supports "@" and relative names when writing out a TargetName in the zone file.  This is useful, but I don't think it has the effect of guiding users toward a good configuration.
> 
> Brian