Bob, One additional consideration that came to mind after my previous message - the apex TXT approach offers advantages in two technical areas: CNAME propagation and DNSSEC signing. (And please correct me if I'm wrong, because I am still very new to this level of depth of DNS standards.) Regarding CNAME propagation:If we use domain.foo IN TXT "_rfcxxx <data>" at the apex domain, and then another domain (domain.bar) sets a CNAME record pointing to domain.foo, the CNAME resolution will automatically include all records at the target domain, including our TXT records. This creates a useful propagation effect.However, with the subdomain approach (_rfcxxx.domain.foo IN TXT "<data>"), if domain.bar sets a CNAME to domain.foo, that CNAME won't automatically propagate to include the TXT records at _rfcxxx.domain.foo. This is because per RFC 1034 section 3.6.2, CNAME records create an alias for the exact domain specified, not for its subdomains.For example:
1. With apex approach: a query for TXT records on domain.bar would return the TXT records from domain.foo 2. With subdomain approach: a query for _rfcxxx.domain.bar would NOT automatically return records from _rfcxxx.domain.foo This behavior is outlined in RFC 1034, which states that CNAME RRs cause "the names in the RDATA field [to be substituted] for the name" in the original query. As described in RFC 2181 section 10.1, this substitution only applies to the exact name, not to constructed names derived from it.Regarding DNSSEC signing:With the apex TXT approach, all records at domain.foo would be signed by the same DNSSEC authority, providing a consolidated security model. In contrast, the subdomain approach introduces the possibility of delegation, where _rfcxxx.domain.foo could potentially be delegated to a different zone with a different DNSSEC signer.This delegation possibility creates both technical flexibility and security considerations. While it allows domain owners to delegate management of these specific records to specialized services, it also introduces additional complexity in the DNSSEC chain of trust and potentially creates additional attack surfaces if the delegated zone has different security practices or is compromised.I believe both of these technical considerations might be worth discussing when we present the options to the working group. Best regards,Victor On Thu, Mar 6, 2025 at 2:34 PM Victor Zhou <z...@namefi.io> wrote: > Bob, > > On Thu, Mar 6, 2025 at 12:05 PM Bob Harold <rharo...@umich.edu> wrote: > >> >> On Thu, Mar 6, 2025 at 1:44 PM Victor Zhou <z...@namefi.io> wrote: >> >>> >>>> We already have a problem with too many TXT records with the same name >>>> used for different purposes. SPF, various validations, and who knows what >>>> else are all at the same name. Could we do instead: >>>> _RFCxxxx.domain.name IN TXT "<data>" >>>> >>>> That reduces the packet size and the amount of records that the >>>> application has to process and discard, since it will only ask for its own >>>> records. >>>> >>> >>> Agree with you Bob that this is an important decision (whether to do it >>> subdomain or as apex), I can include your feedback in the updated RFC, >>> >>> Here is what I think the tradeoffs of each: (please correct me as wrong) >>> >>> - Subdomain approach (`_rfcxxx.domain.name IN TEXT "<data>"`) is >>> usually managed in a zone *under* `domain.name`, making it more >>> separate, and less spammy, and enable larger numbers of records >>> >> >> The subdomain records would typically be in the same zone. They *can" be >> separated into another zone, if desired. >> > > >> >>> - Apex TXT approach is usually managed in the zone *of* `domain.name`, >>> making it easier to manage, and if the parent zone want to delegate child >>> zone out, having apex TXT record method doesn't interfere with that too. >>> >> >> It would be impossible to delegate TXT records as a separate zone in this >> case. They are in the same zone as the 'domain.name' and whatever other >> records that name has. >> > > > Yes to what you said, Bob. > > What I wanted to highlight a possible consideration is that from the > perspective of "name" TLD (in our `_rfcxxx.domain.name` example), the ` > domain.name` is usually delegating to the zone of `domain.name` (SLD). > apex TXT is always associated with whoever manages `domain.name`. But _ > rfcxxx.domain.name is managed by whoever zone manages _rfcxxx.domain.name, > it could be the same zone of domain.name but also could be its own. One > potential unintended consequence may be people starting to use different RR > types for _rfcxxx.domain.name or even subdomains under <foo>._ > rfcxxx.domain.name. This potential unintended consequence may be good > and may be bad. > > I am personally open to either way. My plan is to present this pending > decision in RFC to the WG and ask for a preferred option. > > > >> -- >> Bob Harold >> >>> >>> >>>> >>>> -- >>>> Bob Harold >>>> >>>> >>>
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
