Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni <[e-mail]>]

On Mon, Aug 29, 2022 at 12:33:55PM -0400, Erik Nygren wrote:

> On paths forward on the draft as it stands to clarify without making
> significant technical changes (which I don't think are necessary):
> 
> * Are there particular clarifications we can/should add to help make
> the current behavior more clear to readers?  For example, would having
> some examples of the failure cases (without changing the semantics)
> help?  Note that since the fallback behavior is a SHOULD not a MUST
> for clients, it can't necessarily be relied upon.


Likely so, especially to illustrate:

    * SVCB/HTTPS lookup failure in the initial SVCB query (i.e. not NOERROR/NODATA
      or NXDOMAIN).

    * SVCB/HTTPS lookup failure after some non-zero number of AliasMode records
      that result in a new target $QNAME.

    * A/AAAA lookup failure of the "final" target name (does this lookup still
      happen if SVCB/HTTPS lookup fails after a non-zero number of
      AliasMode records are processed?)

    * Connection failure to some or all of the targets/ports resolved via SVCB/HTTPS
      records (should/may happy eyeballs probe the resolved SVCB/HTTPS
      targets in parallel with the fallback original name or $QNAME
      fallback?)

Clarify which $QNAME is appended to the target list as a fallback.


> * This might be too much of a technical change at this point,
>   but would it make sense to change the SHOULD to a MAY on client
>   fallback behavior?  Clients implementations may choose to ignore the
>   SHOULD so this doesn't change the contract.

Given the stated permissive stance (to quote Paul Vixie from another
forum/thread: browsers gonna browse), perhaps "MAY" is more appropriate.

> * For the rfc1123 section 2 topic, it may make sense to clarify the text
>  to say "domain name" rather than "hostname":
>
>    > An "alternative endpoint" is a hostname, port number, and other
>    > associated instructions to the client on how to reach an instance
>    > of service.
>
>   Everywhere else in the normative sections such as 1.2 and 2.1 we say
>   that the TargetName is a "domain name" (aligned with the
>   clarification in rfc8499 on the difference between host and domain
>   names).
>
> On the rfc1123s2 front. a corner-case that might be encountered is
> that Proxies might be confused by "When connecting using a SVCB
> record, clients MUST provide the final TargetName and port to the
> proxy" in the case where proxies don't expect a domain name (eg, with
> an underscore prefix).  I don't know if there is any warning we should
> provide about this corner-case, or cover that in the future if it
> turns out to be a problem?

Just saying that it is a domain name does not fundamentally address the
issue, since the draft (almost RFC) in multiple places suggests that
even domain names adorned with attrleaf prefixes are potential owner
names of A/AAAA records, which runs into conflict with 1123 (and as
you note potential issues with proxies, or other software that expects
"hostnames" as valid names for A/AAAA records).

> For the future, there are subsequent drafts that could be introduced:
> 
> * We could add an optional "nofallback" SvcParam to AliasMode as Brian
> suggests, but in a future draft. (This would be the first SvcParam on
> AliasMode, but they are allowed and introducing them might help
> prevent ossification of this extension point.)

Sounds reasonable.

> * Introducing an optional "Alt-Used" equivalent (eg, "Service-Used")
>   that provides information about the SVCB/HTTPS RR path followed
>   would be very useful to service operators.  We got stuck on not
>   finding the right content vs privacy balance here, and experience
>   with Alt-Used is that not all clients will implement it regardless.
>   But if we had this and got enough clients to implement then it could
>   help address some of Brian's concerns about getting better
>   visibility in the fallback case.  (eg, "Service-Used: type=fallback"
>   as an HTTP header)

An interesting idea.  Certainly such signals can be helpful to operators
to detect problems and/or guage when infrastructure changes become
viable.

-- 
    Viktor.