> On Oct 7, 2020, at 12:26 PM, Ben Schwartz > <[email protected]> wrote: > > > > On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson <[email protected] > <mailto:[email protected]>> wrote: > > > On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz <[email protected] > <mailto:[email protected]>> wrote: > On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <[email protected] > <mailto:[email protected]>> wrote: > > Other than the syntactic brevity, is there any functional difference to the > client between a TargetName of "." versus a TargetName of "$HOSTNAME" in the > description above? > > Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are > applied). With the proposed change, "." would always mean $HOSTNAME when a > ServiceMode record is returned directly for the original query. However, if > the ServiceMode record is reached via a CNAME or AliasMode record, then "." > does not correspond to (the original) $HOSTNAME. > > This presents two significant problems. > > First, this (what you write above) means that "." will not be guaranteed 100% > of the time to result in the "correct" value, if I understand correctly. > > I'm not sure what you mean by "correct". With or without this proposal, the > expanded name for "." is well-defined. > > Second, the use of "." by whoever creates the ServiceMode record may not be > aware of how it is reached (e.g. by CNAME or AliasMode records not under > their control or that they are aware of or which may be added later). > > The expanded name does not depend on how the record was reached. I'm merely > trying to point out that, after an alias has been followed, any information > about "$HOSTNAME" has been lost.
+1. The “.” is very clear in meaning, since it is only referring to a name that is in the record itself. It’s not about where the chain comes from. This proposal is only about cleaning up a case where that name in the record has less helpful “_foo" prefixes. We absolutely should keep the “.” meaning as-is for all other cases. Tommy > > ... > As you note below, "@" is available, and while perhaps not as elegant, is > handled in the authority server's loading of zone files, and never results in > dynamic processing or additional handling requirements. I.e. it achieves > maybe 90% of the intended "happy" result, but does so with 100% > interoperability after the zone itself is constructed and loaded. > > My impression is that "@" is always, or nearly always, a zone apex. I expect > that the majority of HTTPS and SVCB records will not be for the zone apex. > Setting a ServiceMode TargetName of @ would instruct those records to use the > A/AAAA records for the apex name. This strikes me as an unlikely > configuration. > > > > First, is the use of the standard zone file construct of "@", which only > exists within the zone master file, and gets substituted on import with > whatever $ORIGIN is. > > Yes, the syntax already supports "@" and relative names when writing out a > TargetName in the zone file. This is useful, but I don't think it has the > effect of guiding users toward a good configuration. > > Brian > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
