On Aug 26, 2022, at 4:29 AM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote:
On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver. To me, this implies that functional
> origin endpoints are likely to be required even if client software gains
> SVCB/HTTPS support.
This is why my suggested client behaviour was cognisant of this impediment.
- If the client's *initial* SVCB lookup succeeds, *then* fallback is
no longer an option.
- If initial SVCB resolution fails (SERVFAIL, timeout, ...)
then the client behaves as though the SVCB record does not exist.
This results in more predictable behaviour, without optimising for
failure.
I don't think "more predictable" is really a desirable or achievable outcome in this case. Sophisticated clients (e.g. web browsers for HTTP, iterative resolvers for DNS) tend to develop highly tuned heuristics and state machines in pursuit of performance and reliability within their particular constraints. I think an instruction not to fall back in this case would likely be ignored.
I definitely agree with all the points that Ben is making here and elsewhere. The practical realities of dealing with new record types, and the evolving heuristics on clients, will determine how the records are used.
It makes sense for informational documents to talk about techniques and best practices—like an updated Happy Eyeballs algorithm to include SVCB logic, but that shouldn’t block anything in the base specification or add overly restrictive requirements today.
Tommy
It also strikes me as questionable from a standards perspective: if SVCB itself is optional, surely the client always has the right to change its mind and disable its support for SVCB? If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).
> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.
Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients.
In addition to the deployment concerns I've mentioned earlier, a deployment of this kind would be intrinsically insecure: a hostile intermediary could override the choice of which semantically distinct service is seen by the client. That's another reason why this configuration is not permitted.
But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.
The same could have been said of EDNS0 fallback, but the IETF wisely did not attempt to leap straight to that configuration in the initial RFC. Instead, we gave client implementors plenty of room to tune their own fallback behaviors, and came back to tighten the system up much later when it became safe to do so.
> Viktor notes with concern that AliasMode is a "non-deterministic
> redirect". Instead, the draft attempts to model the client behavior as a
> preference ordered stack of endpoints:
>
I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.
Indeed, I think this is a clarity/precision problem that we should correct. Specifically, this "final value of $QNAME" endpoint is only used if it is not the initial value of $QNAME (i.e. if an AliasMode record was found).
Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/AAAA records there, making some of the example
configurations in the draft impractical.
I don't agree with this reading of RFC 1123. There is no requirement that address records only be placed on hostnames, and there is no requirement that TargetName be a hostname. If I were making an argument here, it might be about compatibility with RFC 8553 (Attrleaf), but hopefully this is mostly moot per the above.
|
