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
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to