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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
