On 24. 08. 26 21:12, Wes Hardaker wrote:
Roy Arends <[email protected]> writes:
I think there may be a misunderstanding about the purpose of these
ranges.
As I said, I think the purpose has changed from where it started (or my
memory is bad). It's fine if it's changed of course, but we should then
ask is it needed given the underlying assumptions have changed.
The question the ranges answer is simple: when constructing a
referral, should this Delegation Type be included, and should the NS
RRset also be included?
So if I read that right, then all the code bases need to understand it
order to do the right thing anyway? In which case what is the benefit
of having a separate range, as opposed to just assigning new RRTYPES
anywhere int the tree? Unless the goal is to enable a > and < operation
vs a switch statement for when to do something? Is that the new
purpose?
[or maybe I've lost the thread entirely and should stop talking (writing)]
You are right and wrong at the same time because there's multiple actors
involved and only subset needs upgrade.
Compare these two situations.
### Delext does not exist
DELEG is done as one-off, without the range allocation. All signers,
validators, resolvers, and auths have to be upgraded (not mentioning
provisioning systems etc.) to make DELEG work.
For DELEG2 (hypothetical version 2) again, 'everything' needs to be
upgraded because it is a parent-side RR type. In scenarios without
delext, only DS and DELEG are hardcoded special cases.
DELEG2-supporting resolver cannot forward through DELEG(version
1)-only-supporting resolver.
### With delext
Delext support (the range!) requires all signers, validators, resolvers,
and auths have to be upgraded (+ possibly provisioning systems) to make
the new range work.
DELEG then piggybacks on delext and _only resolvers_ (and provisioning)
need to have extra code/get an upgrade to make use of DELEG. Other parts
of system remain unaffected.
If DELEG2 comes along, again only resolvers (and provisioning) need an
upgrade. At the same time, DELEG2-supporting resolver _can_ forward
through DELEG-only-supporting resolver because the behavior for the
range is well defined.
The same goes for other example RR types from other ranges - DS2, PSL,
DBOUND etc.
In other words, delext makes most of the ecosystem extensible with
parent types and only consumers (resolvers) of the new types will need a
code change in future, when a new RR type is allocated.
Does it make sense now?
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
