[DNSOP] Re: DNSOPDELEXT: Proposed Delegation Type Ranges

> On 24 Aug 2026, at 13:55, Wes Hardaker <[email protected]> wrote:
> 
> Petr Špaček <[email protected]> writes:
> 
>> I like examples, so I will provide TL;DR examples:
> 
> Thanks; they're helpful reading.
> 
> I have to say, my reaction to the fact we've come up with 4 categories
> (ok, 3 really) for future expansions that *may* be needed leads me to
> think we probably haven't actually identified all the crazy things we
> will do in the future, and the likelihood of this actually assuredly
> solving the more permanent problem of "will the authoritative server
> need to change its logic because of this new data type" leads me think
> only "maybe".
> 
> Now, if we can successfully predict even some ranges of code, then this
> is likely a useful thing to do.
> 
> But I thought the original intent, when this discussion stared a while
> ago, was really: when should an engine know that a new RRTYPE is
> critical and you should abandon hope in some way because you don't
> understand it.  Or maybe I misunderstood the original goal (very
> entirely possible), but if not: then how does a new set of ranges change
> this semantic?  Are we confident that now there are 3 slices of
> different code that these new types can be treated generically in some
> way?  I have doubts...  And shouldn't there be another range for
> "abandon all hope because it turns out there is a category we failed to
> predict back then and need to assign it now"?
> 
> Reader be warned: It may be that at 5:30 in the morning I shouldn't be
> thinking about hard problems.

I think there may be a misunderstanding about the purpose of these ranges.

The sole purpose of the ranges is response size optimisation. They are not intended to predict the semantics of future Delegation Types, nor to determine whether an implementation understands a particular type. 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?

That gives us three useful behaviours:

Range 1: include the Delegation Type, omit NS.
Range 2: include the Delegation Type, retain NS.
Range 3: do not include the Delegation Type in the referral; return it only when explicitly queried.

The motivation is to avoid sending information that is either redundant or unnecessary in every referral, while still allowing future Delegation Types to be introduced without changing the basic referral machinery.

So I don’t think we need an “abandon all hope” range. If a future Delegation Type introduces semantics that require an authoritative server to understand the type, that is a separate extensibility problem and would need to be specified by that future mechanism. These ranges are not intended to solve that problem. They are deliberately much more modest. Encode enough information to let an authoritative server construct a reasonably sized referral without understanding the semantics of each individual Delegation Type.

Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]