-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In this example, there are two services provided by one endpoint, for a total of three domain names.
Using "target.example." for the HTTPS record would incorrectly assert that it provides an HTTPS service for itself. It would also prevent that domain from using HTTPS records for itself with different parameters. Using another domain, such as "alt.target.example.", would be similarly misleading. RFC 8552 reserves all global underscored node names for use according to an IANA registry, and specifies that they are meant to act as attributes for the non-underscored parent domain. That makes them ideal for this scenario, except that there is no suitable node name assigned: using an unassigned node name could cause issues if it is assigned in the future. What I am proposing is simply that "_private" be added to the registry, with no meaning beyond assuring that IANA will not assign it for something in the future. To put it another way, no special meaning will ever be ascribed to it by anyone other than the domain holder, and as a result there will never be a collision. This is basically the same as the "_example" node name that is already reserved, except intended for actual use. target.example. AAAA 2001:db8:: target.example. HTTPS 0 . _443._tcp.target.example. CNAME local-user._private.target.example. _443._quic.target.example. CNAME local-user._private.target.example. local-user._private.target.example. HTTPS 1 pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion. alpn="h2" local-user._private.target.example. HTTPS 2 target.example. alpn="h3,h2" local-user._private.target.example. TLSA 3 1 1 8a9a70596e869bed72c69d97a8895dfad86f300a343feceff19e89c27c896bc9 alfa.example. HTTPS 0 local-user._private.target.example. bravo.example. HTTPS 0 local-user._private.target.example. -----BEGIN PGP SIGNATURE----- iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY7SYaFYYJ2h0dHBzOi8v b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1DaAQC31elj 44+eHSaC1z7NBsI45Zhk7ZjQDzs6xH5xgchwEgD/QOFWr+j8JqFsWAMbya+CriWZ 6grC3Dg+SxFfE8Y2sgg= =P1yq -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
