On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz <[email protected]> wrote:
> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson < > [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. 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). Unless I misunderstand, I think the lack of 100% correctness in all scenarios means this will cause difficult-to-find-and-fix operational problems. For this reason, I strongly suggest removing the "." and its special handling. 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. > > 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
