On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz <bem...@google.com> wrote:
> > > On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> Fail fast may not be appealing, but in some (probably the majority of) >> cases, it may be the most correct option. >> >> It may also be the case that the zone owner knows whether this is the >> case. >> I think it is much more likely that explicitly declaring the situation >> (if known) is more useful than having several billion clients independently >> attempting to infer whether the first option will even work, let alone >> provide a useful alternative to the second or third. >> > > In fact, there is one way for the zone owner to disable fallback: enable > ECH. Fallback is not compatible with ECH, so ECH-aware clients will > disable fallback when the ServiceMode records contain ECH. > > Wait, what? This whole discussion was raised from the perspective of zone owners publishing AliasMode apex records. Those owners would not be operating the CDN, which is the whole point of using a CNAME or AliasMode. I.e., the zone owner would be the one wanting to disable fallback, but would not be in a position to do what you suggest. The domain's contents are served via a CDN, where the CDN requires delegation of control, most often with CNAME (or AliasMode at the apex). The ServiceMode records are placed on the CDN operated zone (in order to avoid the first connection to establish the AltSvc stuff). The AliasMode record cannot be combined with ECH, since no SvcParams are allowed. The zone owner is not using ServiceMode, that is the declared assumption. If that (ECH) is the only way to disable fallback, that's what the focused discussion needed to elicit, and I think some slight adjustments are needed to at least facilitate zone owners preventing fallback. The mechanism doesn't need to be added to the draft, but likely would get put into a separate draft or a -bis document. However, there needs to be some daylight between the fallback method and the mandatory SVCB/HTTPS components, in order to allow for that development. BTW, the concern is less about singleton zone owners than it is about large scale integrated DNS management of zones in order to accommodate CDN usage. Note also, this issue is not strictly limited to vertical integration among products/services of the DNS operator; there are large scale inter-provider (DNS and other services) open partnerships (controlled by their mutual customers) that have need for the programmatic ability to assign CDNs and enable/disable fallback (if fallback is part of the specification). (For those interested, the not-yet-an-IETF standard for interoperability between DNS and service providers is Domain Connect. The intent is to revive the draft for that, which previously lived in the REGEXT WG.) I think converting the fallback in the draft into MAY, and having active discussions, dev, test, and deployment on a voluntary basis outside of the scope of the current draft, is the fastest path to solving the "no fallback" signaling issue, and to getting the draft published (with a few minor tweaks). I'll review the other comments, as well as Warren and Viktor's recent messages, and see if I can come up with some proposed text to make very limited changes to the draft. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
