I don’t personally find this proposal to be an improvement for clarity. The fact that a client is SVCB-optional means, somewhat by definition, that they allow not using the SVCB results. Saying that the client “MAY” doesn’t really help; it’s the very definition of what SVCB-optional is. If the client doesn’t use non-SVCB connection modes at that point, then it is SVCB-reliant.
Listing out the details of what a non-SVCB connection does (not using the information from the SVCB record) also seems redundant. It is more accurate to just say “don’t use anything from SVCB if SVCB didn’t work” rather than trying to list out what all of those details might be. Tommy > On Aug 31, 2022, at 4:13 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > So, here is my suggestion, for "a sentence (or possibly two) which only > clarify what is already written?": > > In section 3: > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client now attempts to use non-SVCB > connection modes. > becomes: > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client MAY attempt to use non-SVCB > connection modes, using the origin name (without prefixes), > the authority endpoint's port number, and no SvcParams. > > (The original didn't use RFC 2119 language, but the list of failure modes in > 3.1 leads to "MAY" being the most appropriate choice.) > > Let me know if that is good enough. > (The rest can go into a -bis... how soon are we allowed to start a -bis > document? The day of RFC publication? I'd like to start that as soon as > possible, while everything is still fresh.) > > Brian > > On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari <war...@kumari.net > <mailto:war...@kumari.net>> wrote: >> >> >> >> >> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson >> <brian.peter.dick...@gmail.com <mailto:brian.peter.dick...@gmail.com>> wrote: >>> Here are some proposed text changes, per Warren's invitation to send text: >> >> >> >> Um, no. Warren said: "can we craft a sentence (or possibly two) which only >> clarify what is already written?". This is a significantly larger set of >> changes than that. The Section 3 changes in particular are (IMO) much more >> than a clarification. >> >> These may or may not be good changes, but anything approaching that level of >> change would have to be in a -bis document… >> >> W >> >> >>> >>> In section 1.2, change: >>> 2. TargetName: The domain name of either the alias target (for >>> AliasMode) or the alternative endpoint (for ServiceMode). >>> to: >>> 2. TargetName: Either the domain name of the alias target (for >>> AliasMode) or the host name of the alternative endpoint (for >>> ServiceMode). >>> >>> In section 2.4.2, change: >>> As legacy clients will not know to use this record, service operators >>> will likely need to retain fallback AAAA and A records alongside this >>> SVCB record, although in a common case the target of the SVCB record >>> might offer better performance, and therefore would be preferable for >>> clients implementing this specification to use. >>> to: >>> As legacy clients will not know to use this record, service operators >>> will likely need to retain fallback AAAA and A records at the service >>> name, >>> although in a common case the target of the SVCB record >>> might offer better performance, and therefore would be preferable for >>> clients implementing this specification to use. >>> >>> In section 2.4.3, change: >>> In ServiceMode, the TargetName and SvcParams within each resource >>> record associate an alternative endpoint for the service with its >>> connection parameters. >>> to: >>> In ServiceMode, the TargetName and SvcParams within each resource >>> record associate an alternative endpoint for the service with its >>> connection parameters. The TargetName MUST be a host name >>> (as defined in [DNSTerm].) >>> >>> In section 3, the following changes are proposed; they introduce a new term >>> LASTNAME to be used to disambiguate the $QNAME reference so as to remove >>> ATTRLEAF prefixes from the appended target: >>> >>> 1. Let $QNAME be the service name plus appropriate prefixes for the >>> scheme (see Section 2.3). >>> becomes: >>> 1. Let $QNAME be the service name plus appropriate prefixes for the >>> scheme (see Section 2.3). Let $LASTNAME be the service name without >>> any prefixes. >>> >>> >>> 3. If an AliasMode SVCB record is returned for $QNAME (after >>> following CNAMEs as normal), set $QNAME to its TargetName >>> (without additional prefixes) and loop back to step 2, subject to >>> chain length limits and loop detection heuristics (see >>> Section 3.1). >>> becomes: >>> 3. If an AliasMode SVCB record is returned for $QNAME (after >>> following CNAMEs as normal), set $QNAME to its TargetName >>> (without additional prefixes), set $LASTNAME to this new $QNAME and >>> loop back to step 2, subject to >>> chain length limits and loop detection heuristics (see >>> Section 3.1). >>> >>> Once SVCB resolution has concluded, whether successful or not, SVCB- >>> optional clients SHALL append to the priority list an endpoint >>> consisting of the final value of $QNAME, the authority endpoint's >>> port number, and no SvcParams. (This endpoint will be attempted >>> before falling back to non-SVCB connection modes. This ensures that >>> SVCB-optional clients will make use of an AliasMode record whose >>> TargetName has A and/or AAAA records but no SVCB records.) >>> becomes: >>> Once SVCB resolution has concluded, whether successful or not, SVCB- >>> optional clients SHALL append to the priority list an endpoint >>> consisting of the final value of $LASTNAME, the authority endpoint's >>> port number, and no SvcParams. (This endpoint will be attempted >>> before falling back to non-SVCB connection modes. This ensures that >>> SVCB-optional clients will make use of an AliasMode record whose >>> TargetName has A and/or AAAA records but no SVCB records.) >>> >>> If the client is SVCB-optional, and connecting using this list of >>> endpoints has failed, the client now attempts to use non-SVCB >>> connection modes. >>> becomes: >>> If the client is SVCB-optional, and connecting using this list of >>> endpoints has failed, the client MAY attempt to use non-SVCB >>> connection modes, using the origin name (without prefixes), >>> the authority endpoint's port number, and no SvcParams. >>> >>> One additional suggested addition to the end of section 3.1 is: >>> If DNS responses are cryptographically protected, and at least >>> one HTTPS AliasMode record has been received successfully, >>> clients MAY apply Section 9.5 (HSTS equivalent) restrictions >>> even when reverting to non-SVCB connection modes. Clients >>> also MAY treat resolution or connection failures subsequent >>> to the initial cryptographically protected AliasMode record >>> as fatal. >>> [Brian's note: this last would provide some guidance to implementers of >>> clients: a signed HTTPS AliasMode record is a strong signal that the DNS >>> operator is discouraging fallback, albeit at a "MAY" level.] >>> >>> NB: The 2.4.3 change could be removed as it is mostly independent, as could >>> the last addition to 3.1. >>> The 1.2 change is very minor, is not too important but presents a succinct >>> clarification on the hostname vs domain name thing. >>> The 2.4.2 change and section 3 changes together are fixes for the >>> prefix/no-prefix issue (which was basically a scrivener's error, and does >>> not change the semantics at all.) They should stay or go as one unit. >>> >>> Brian >>> >>> On Tue, Aug 30, 2022 at 12:08 AM Brian Dickson >>> <brian.peter.dick...@gmail.com <mailto:brian.peter.dick...@gmail.com>> >>> wrote: >>>> >>>> >>>> On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz <bem...@google.com >>>> <mailto:bem...@google.com>> wrote: >>>>> >>>>> >>>>> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson >>>>> <brian.peter.dick...@gmail.com <mailto: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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
