On 24. 08. 26 17:05, Philip Homburg wrote:
It feels to me DELEG / DELEXT is adding a lot of complexity for
what is ultimately a small use case (let DNS hosters update DNSSEC
KSKs) to the point where perhaps a DNS v2.0 from scratch would be
better.
I disagree.
dprive was stuck for years and did not come up with any authenticated
signal - mostly because lacked proper extensibility at the parent side.
To me if feels the DELEG path is becoming more and more a stack of
nifty hacks.
I share your concern. This aspect of DELEG is the result of the introduction
of new parent-side types. And, given how painful it is to introduce a single
new parent-side type, to create a general mechanism that makes it easier
in the future.
Exactly. The whole purpose of delext is to pay the price and 'buy a
range' instead of paying essentially the same price for just one RR type
number.
The question then becomes, what can you do without new parent-side types.
Quite a lot. But those approaches bring their own limitations and complexity.
I agree alternatives (personally I would call them hacks) are possible.
dprive explored quite some and did not find any hack agreeable to enough
people to make it into an RFC.
From this perspective delext looks like paying back the technical debt
- i.e. lack of extensibility in the parent. Interest on that debt will
get only higher with time.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
