[DNSOP] Re: Is DELEXT too restrictive?

--===============0374427324507355260==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C6C9E508-F734-41A0-B480-83384981BDBF"


--Apple-Mail=_C6C9E508-F734-41A0-B480-83384981BDBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 29 Jul 2026, at 12:56, Philip Homburg <[email protected]> =
wrote:
>=20
>> The DE flag was introduced as a capability negotiation mechanism,
>> indicating that the resolver understands DELEG. Omitting the NS
>> RRset was a natural  optimisation of the protocol semantics adopted
>> for DELEG (why send NS it if it is not used), but not the purpose
>> of the DE flag itself.
>=20
> For unsigned zones, there is no need for a capability negotiation. =
Just
> putting both NS and DELEG records in the Authority section is fine.=20
> If I remember correctly, somebody tested whether this would cause any
> problems. So originally, DE was just an optimization.

Philip, My recollection is slightly different.

The DE flag really was introduced as a capability negotiation mechanism. =
Later, it turned out that sending both NS and DELEG in the referral =
didn=E2=80=99t actually cause interoperability problems (I believe =
Shumon and I were the ones who tested this).

Even after that, we kept the DE flag because it provided a useful signal =
for measuring deployment and adoption.

My recollection is also that the current behaviour (sending either NS or =
Delegation Types depending on the value of the DE flag) came later. In =
other words, I don=E2=80=99t think DE was originally introduced as an =
optimisation; the optimisation followed from the protocol semantics that =
eventually evolved around it.

In any case, I don=E2=80=99t think the historical motivation is the =
important question. The question today is whether DELEG/DELEXT should =
define the NS interaction for all future Delegation Types, or whether =
that should be left to the individual Delegation Type specifications.


> Later it was found that sending DELEG records to legacy resolvers =
could
> cause DNSSEC validation errors. So DE became required, but that does
> not change the original purpose of DE.
>=20
>>> do we want the extra
>>> complexity for this optimization or not. What does it mean =
operationally,
>>> when delegation replies get bigger due to inclusion of NS records.
>>=20
>> The Response size gets larger when all Delegation Types and NS
>> records are included, compared to solely Delegation Types. That is
>> indeed a consequence of my proposed modification. However, new
>> Delegation Types do not necessarily need to have a DELEG RRset, so
>> the cost of larger responses now should be offset against even
>> larger responses in the future, if we dont make the change.
>=20
> One option is to split the range of new parent types into delegation =
types
> and informational types. That makes it possible to keep the =
optimization
> while allowing new types that can be combined with NS.

Assume that, in the future, a new Delegation Type supersedes DELEG. =
Existing resolvers understand DELEG and NS, but not the new type.

With the current DELEXT semantics (or with a split where =E2=80=9Cdelegati=
on types=E2=80=9D suppress NS), the referral would contain the new =
Delegation Type but no NS RRset. Since the resolver doesn=E2=80=99t =
implement the new Delegation Type, it cannot use it, and because there =
is no NS RRset, it cannot fall back to the legacy delegation either. The =
delegation therefore becomes unusable for those resolvers.

My suggestion is slightly different. If a resolver does not implement =
any of the Delegation Types in the referral, but the referral validates =
correctly, it falls back to the NS RRset. Therefore the NS RRset needs =
to be included in the referral.

On the other hand, if the resolver does implement a Delegation Type, it =
follows that Delegation Type=E2=80=99s specification. If that =
specification requires that NS not be used (as DELEG does), then the =
resolver MUST ignore the NS RRset.=20

This is similar in spirit to DNSSEC algorithm agility. A resolver is not =
expected to understand future algorithms immediately; the protocol =
defines how implementations behave until they do. I=E2=80=99m suggesting =
DELEXT should provide a similar compatibility story for future =
Delegation Types, rather than requiring every future =E2=80=9Cdelegation=E2=
=80=9D type to inherit DELEG=E2=80=99s semantics.

Roy=

--Apple-Mail=_C6C9E508-F734-41A0-B480-83384981BDBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On 29 Jul 2026, at 12:56, Philip Homburg =
&lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div><blockquote =
type=3D"cite">The DE flag was introduced as a capability negotiation =
mechanism,<br>indicating that the resolver understands DELEG. Omitting =
the NS<br>RRset was a natural &nbsp;optimisation of the protocol =
semantics adopted<br>for DELEG (why send NS it if it is not used), but =
not the purpose<br>of the DE flag itself.<br></blockquote><br>For =
unsigned zones, there is no need for a capability negotiation. =
Just<br>putting both NS and DELEG records in the Authority section is =
fine. <br>If I remember correctly, somebody tested whether this would =
cause any<br>problems. So originally, DE was just an optimization. =
<br></div></div></blockquote><div><br></div><div><p class=3D"p1">Philip, =
My recollection is slightly different.</p><p class=3D"p1">The DE flag =
really was introduced as a capability negotiation mechanism. Later, it =
turned out that sending both NS and DELEG in the referral didn=E2=80=99t =
actually cause interoperability problems (I believe Shumon and I were =
the ones who tested this).</p><p class=3D"p1">Even after that, we kept =
the DE flag because it provided a useful signal for measuring deployment =
and adoption.</p><p class=3D"p1">My recollection is also that the =
current behaviour (sending either NS or Delegation Types depending on =
the value of the DE flag) came later. In other words, I don=E2=80=99t =
think DE was originally introduced&nbsp;<span =
class=3D"s1"><i>as</i></span>&nbsp;an optimisation; the optimisation =
followed from the protocol semantics that eventually evolved around =
it.</p></div><div><p class=3D"p1">In any case, I don=E2=80=99t think the =
historical motivation is the important question. The question today is =
whether DELEG/DELEXT should define the NS interaction for all future =
Delegation Types, or whether that should be left to the individual =
Delegation Type specifications.</p></div><div><br></div><blockquote =
type=3D"cite"><div><div>Later it was found that sending DELEG records to =
legacy resolvers could<br>cause DNSSEC validation errors. So DE became =
required, but that does<br>not change the original purpose of =
DE.<br><br><blockquote type=3D"cite"><blockquote type=3D"cite">do we =
want the extra<br>complexity for this optimization or not. What does it =
mean operationally,<br>when delegation replies get bigger due to =
inclusion of NS records.<br></blockquote><br>The Response size gets =
larger when all Delegation Types and NS<br>records are included, =
compared to solely Delegation Types. That is<br>indeed a consequence of =
my proposed modification. However, new<br>Delegation Types do not =
necessarily need to have a DELEG RRset, so<br>the cost of larger =
responses now should be offset against even<br>larger responses in the =
future, if we dont make the change.<br></blockquote><br>One option is to =
split the range of new parent types into delegation types<br>and =
informational types. That makes it possible to keep the =
optimization<br>while allowing new types that can be combined with =
NS.<br></div></div></blockquote><br></div><div><p class=3D"p1">Assume =
that, in the future, a new Delegation Type supersedes DELEG. Existing =
resolvers understand DELEG and NS, but not the new type.</p><p =
class=3D"p1">With the current DELEXT semantics (or with a split where =
=E2=80=9Cdelegation types=E2=80=9D suppress NS), the referral would =
contain the new Delegation Type but no NS RRset. Since the resolver =
doesn=E2=80=99t implement the new Delegation Type, it cannot use it, and =
because there is no NS RRset, it cannot fall back to the legacy =
delegation either. The delegation therefore becomes unusable for those =
resolvers.</p><p class=3D"p1">My suggestion is slightly different. If a =
resolver does not implement any of the Delegation Types in the referral, =
but the referral validates correctly, it falls back to the NS RRset. =
Therefore the NS RRset needs to be included in the referral.</p><p =
class=3D"p1">On the other hand, if the resolver does implement a =
Delegation Type, it follows that Delegation Type=E2=80=99s =
specification. If that specification requires that NS not be used (as =
DELEG does), then the resolver MUST ignore the NS RRset.&nbsp;</p><p =
class=3D"p1">This is similar in spirit to DNSSEC algorithm agility. A =
resolver is not expected to understand future algorithms immediately; =
the protocol defines how implementations behave until they do. I=E2=80=99m=
 suggesting DELEXT should provide a similar compatibility story for =
future Delegation Types, rather than requiring every future =
=E2=80=9Cdelegation=E2=80=9D type to inherit DELEG=E2=80=99s =
semantics.</p></div><div>Roy</div></body></html>=

--Apple-Mail=_C6C9E508-F734-41A0-B480-83384981BDBF--


--===============0374427324507355260==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============0374427324507355260==--