Am I interpreting the idea correctly that the goal here is to be able to create names that are only usable as alias targets?
If so, interesting idea, but I'm not sure such a mechanism could actually be created and widely implemented. I don't think there's enough motivation for all the relevant implementors to add code to block a previously-allowed name for non-alias use or to allow a previously-disallowed name just for alias use, so it just doesn't seem feasible unless all the implementations are already handling underscore-prepended names the way we want and I don't think that's the case. Too much stuff would just allow "_private" names to be resolved as a normal hostname, and I don't think you're going to convince everybody that it's worth the effort to add special code to block it. On Tue, Jan 3, 2023 at 2:45 PM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote: > Hi Jeremy, > > This is an interesting idea, but I think it's difficult to understand in > the abstract. Could you provide some example zone files for the use case > you're considering? > > It sounds like you're concerned about the possibility that non-underscored > names could be misconstrued as host names, even though they don't hold any > address records. However, I don't believe there is any general expectation > that DNS names must be the names of hosts just because they are > syntactically valid hostnames. > > Thanks, > Ben > > On Thu, Dec 8, 2022 at 6:39 PM Jeremy Saklad <jeremy= > 40saklad5....@dmarc.ietf.org> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> BCP 222 sets out guidelines for using underscored DNS node names, which >> are important for any record that should not be mistakenly interpreted as >> an actual host. However, it doesn’t seem to set aside a name for private >> use, which would be particularly helpful for deduplicating RRsets. >> >> As an example, draft-ietf-dnsop-svcb-https-11 suggests using AliasMode >> HTTPS records to maintain a separation of concerns. I’ve found this helpful >> myself, as it allows me to have the configuration for a web server and >> single onion service in one RRset, with each of the served hostnames >> aliasing to that. >> >> However, that suggestion recommends using non-underscored TargetNames, >> which have the side-effect of incorrectly stating that the TargetName is >> itself an origin. It would make much more sense to alias to an underscored >> node name for this. >> >> Upon looking into my options, however, I can’t find any >> standards-compliant way of actually doing that. The closest option is >> “_example”, which doesn’t seem meant for actual use. Am I missing >> something, or is it outright impossible to name arbitrary DNS records >> without the possibility that future specifications ascribe unwanted meaning >> to it? >> >> If I am in fact not missing anything, I propose registering “_private” as >> a reserved node name for all RRTypes. >> -----BEGIN PGP SIGNATURE----- >> >> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY5J1DVYYJ2h0dHBzOi8v >> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw >> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1hwAP9fQoJv >> UrWZA8GnQWK+sStyneA4t5IsTOmOSdto4wcziQD/ajah2eIyUr8rOkRoM2DveTQF >> bl6EvRxLsQR2TjCmBQc= >> =xghv >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
