Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and Eric Orth that the current behavior makes sense and that no fundamental technical change is needed. No matter what we do, odd faults and misconfigurations will happen and Postel's law applies. Client implementers will try and be liberal with what they accept (as long as doing so doesn't introduce security issues, such as if you know you have bad data), and even then some client implementers may ignore this and still try to be robust.
On the "how to sell this behavior", beyond giving client implementers the ability to be robust, there will be clients not implementing SVCB/HTTPS RRs behavior for a long time to come, so fallbacks will be needed for a long time. HTTPS RR in particular is specified as SVCB-optional. I think some confusion keeps coming from a desire to think of AliasMode SVCB RRs as "CNAMEs that can live at the apex" which they are not, even if they can help solve that problem. Brian, if I understand it right your 301 redirect approach seems like a reasonable way to address the fallback and legacy client case (and as clients pick this up the need for those redirects should decrease). 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. * 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. * 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? 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.) * 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) Erik
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
