Hi Petr, > On 1 Jul 2026, at 13:03, Petr Špaček <[email protected]> wrote: > > On 29. 06. 26 17:59, [email protected] wrote: >> Name: draft-ietf-dnsop-delext-07.txt > > I'm seeking wisdom of WG about couple things: > >> 3.1.1. Criteria for Delegation Type Allocation The RR type is intended >> to appear at a delegation point as authoritative data in the delegating >> zone, in a manner analogous to the DS record as defined in [RFC4034]. >> The RR type carries information that is intended to be acted upon by a >> resolver during the process of following a referral. This includes >> information used prior to sending queries to the authoritative servers for >> the delegated zone, or after the referral has been followed, such as >> material used to authenticate a DNSKEY in the delegated zone. >> The RR type is not intended to appear as authoritative data within the >> delegated zone itself. >> RR types that do not meet all of these criteria MUST NOT be allocated from >> the Delegation Types range. >> A record type may be useful in the context of delegation, but that does not >> by itself qualify it for allocation as a Delegation Type. Record types that >> convey information useful to resolvers but that are intended to appear >> within a zone rather than at its delegation point in the delegating zone are >> Data Types and MUST be allocated accordingly. > > I wonder if we want to explicitly allow things which are not strictly > delegation or DNSSEC but are somehow related to the structure of DNS > namespace. Say DBOUND came up with a RR type which denotes ... something ... > and they wanted to put that next to NS/DELEG RRsets. > > How does that sound?
Sounds good. > My point is - we have DS type which is not a delegation, but bunch of octets > next to delegation. Perhaps there will be use-case for something similar down > the road, and I would hate to go through the same process only because we > painted ourselves into a corner. > > I wonder if this falls within 'policy information' mentioned in Appendix A? >> Appendix A. Services Provided by Delegation Types >> Services provided by Delegation Types consist of information useful to a >> resolver when connecting to servers responsible for the delegated namespace. >> This can include, but is not limited to, secure transport parameters, policy >> information about zones, and DNSSEC security parameters. > The reason it is in the appendix is that it is not that relevant to the protocol. Note that the summation in the appendix is preceded with “,but is not limited to”. How about a small wording change: Before: Services provided by Delegation Types consist of information useful to a resolver when connecting to servers responsible for the delegated namespace. After: Services provided by Delegation Types consist of useful information about the delegated namespace. > >> 3.1.2. Private Use Range >> The range 0xF1F0-0xF1FF is reserved for Private Use in accordance with >> [RFC8126]. Values in this range MUST NOT be published in zones intended for >> the public DNS and MUST NOT be used in any context where interoperability >> with implementations outside a private network is required. > > I think we should remove sentence "Values in this range MUST NOT be published > in zones intended for the public DNS" and keep only "MUST NOT be used in any > context where interoperability with implementations outside a private network > is required.". Otherwise we would need sub-range for experiments, and I think > it is not necessary. > > What does the group think? I agree. This was too prescriptive on my side. Paul Hoffman also pointed that out recently. Happy to remove it. > Last, one nitpick I can't decide how to approach: > > > 3. Delegation Types > > > > [RFC6895] lists three subcategories of RR type numbers: data TYPEs, QTYPEs, > > and Meta-TYPEs. This specification adds a fourth subcategory: Delegation > > Types. > > > > Section 9.3 requests IANA to allocate the ranges 0xF000-0xF1EF and > > 0xF1F0-0xF1FF for Delegation Types. > > Do people find it confusing that the original NS RR type is not labeled as > 'Delegation Type'? > > I'm trying to find a way to say 'NS also creates delegation, but it is not > labeled as Delegation Type because ...' but I'm coming up blank. Perhaps it's > just in my head, but I wanted to check. The original term was “Authoritative Delegation Type” which makes it explicitly distinctive from delegation point NS records. I can precede all the occurrences of Delegation Type with “Authoritative” if that makes folk happy. — _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
