> The DNSOP WG has placed draft-arends-dnsop-delext in state Call > For Adoption By WG Issued (entered by Peter Thomassen)
I have comments that may require some reflection early on. The first is that the draft mentions DS records and later says "This can include, but is not limited to, secure transport parameters, policy information about zones, and DNSSEC security parameters." A DNSSEC validator that forwards to a legacy recursive solver (one that does not implement this draft) will have a hard time using the information in the new delegation types. It is quite possible that in the coming decade(s) the use of these new types will be limited to data that is useful to recursive resolvers. And, for example, cannot be used to define new types of DNSSEC delegation. Not a direct problem for this draft as it mostly reserves a range of code point. But it does limit the use of the draft a bit. The second issue is the specification of the EDNS(0) DE bit. As far as I know, it is perfectly safe to return NS records along with DELEG records when DE=1. It is an optimization to leave out the NS records. It gets a lot more complex when DE=0 and only DELEG records exist at a delegation. So what happens if we start using this range, and allocate a DELEG2 RRtype. Does that also mean allocating a DE2 bit? Does the DE bit mean that both the DELEG and the DELEG2 need to be returned in a delegation? _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
