[DNSOP] Re: DNSOPDELEXT: Proposed Delegation Type Ranges

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]