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?
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.
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?
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.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
