[DNSOP] Re: Is DELEXT too restrictive?
Roy Arends <[email protected]> Mon, 3 Aug 2026 20:49:44 +0100
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
--===============8790147304812880456== Content-Type: multipart/alternative; boundary="Apple-Mail=_CAD314DF-5311-4A52-9ED6-743902122A1E" --Apple-Mail=_CAD314DF-5311-4A52-9ED6-743902122A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3 Aug 2026, at 16:49, Philip Homburg <[email protected]> = wrote: >=20 >> I think were looking at this from slightly different angles. >>=20 >> My example isnt intended to describe what I think operators will >> do. Its intended to show what the protocol permits. >>=20 >> Currently, DELEXT specifies that every future Delegation Type >> inherits DELEGs interaction with NS (i.e. ignore NS) by default. >> My concern is whether thats the right architectural choice for a >> framework intended to support future Delegation Types. >>=20 >> I also dont think the issue is specific to a hypothetical DELEG2. >> It applies to any future Delegation Type that does not need DELEGs >> NS replacing semantics. Under the current design, such a type either >> has to require DELEG alongside it, or it has to change DELEXT. >> Thats the design choice Im asking the working group to make >> consciously now, rather than implicitly through DELEG. >=20 > We can split the range in two Philip, I appreciate that you acknowledge that there is an issue to be = solved! > - one part is for new delegation types. The assumption is that DELEG = and > any future delegation type will completely replace NS. So we can = optimize > delegation replies and leave out NS. > - the other part is for non-delegation server-side types like DS. We = can assume > that they complement any delegation type including NS.=20 >=20 > If we assume new types DELEG2 and DS2. Then a delegation that has both=20= > NS and DELEG2 and the query has DE=3D1 then only DELEG2 would be = returned. > A delegation with both NS and DS2 (and a DE=3D1 query) would get both = NS and DS2.=20 > A delegation with NS, DELEG2, and DS2 (and a DE=3D1 query) would get = DELEG2 > and DS2. Consider a resolver understands DS2, but not DELEG2. Since the = authoritative server omitted the NS RRset, the resolver has no = delegation information it can actually use.=20 To allow the internet to migrate from DELEG to DELEG2, operators would = therefore need to deploy both DELEG and DELEG2, each with its own = signatures, until DELEG2 is universally implemented. That seems like a = fairly high deployment cost to preserve a relatively small optimisation = in referral size. > I think that solves the problem. Though at the cost of a bit of extra > complexity. Is there any objection to splitting the range? I think my proposal keeps DELEXT itself simpler. Rather than having the = generic protocol decide, based on a type range, whether NS is replaced, = each Delegation Type defines its own interaction with NS. Existing = implementations automatically have a well-defined compatibility = behaviour for future Delegation Types that they do not yet implement. That=E2=80=99s also why I drew the analogy with DNSSEC algorithm = agility. The protocol defines how implementations behave when they = encounter something they don=E2=80=99t yet understand, rather than = requiring future extensions to inherit the semantics of today=E2=80=99s = ones. Roy= --Apple-Mail=_CAD314DF-5311-4A52-9ED6-743902122A1E 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;"><div 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 3 Aug 2026, at 16:49, Philip Homburg = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div><blockquote type=3D"cite">I = think were looking at this from slightly different angles.<br><br>My = example isnt intended to describe what I think operators will<br>do. Its = intended to show what the protocol permits.<br><br>Currently, DELEXT = specifies that every future Delegation Type<br>inherits DELEGs = interaction with NS (i.e. ignore NS) by default.<br>My concern is = whether thats the right architectural choice for a<br>framework intended = to support future Delegation Types.<br><br>I also dont think the issue = is specific to a hypothetical DELEG2.<br>It applies to any future = Delegation Type that does not need DELEGs<br>NS replacing semantics. = Under the current design, such a type either<br>has to require DELEG = alongside it, or it has to change DELEXT.<br>Thats the design choice Im = asking the working group to make<br>consciously now, rather than = implicitly through DELEG.<br></blockquote><br>We can split the range in = two<br></div></div></blockquote><div><br></div><div>Philip, I appreciate = that you acknowledge that there is an issue to be = solved!</div><br><blockquote type=3D"cite"><div><div>- one part is for = new delegation types. The assumption is that DELEG and<br> any = future delegation type will completely replace NS. So we can = optimize<br> delegation replies and leave out NS.<br>- the other = part is for non-delegation server-side types like DS. We can assume<br> = that they complement any delegation type including NS. <br><br>If = we assume new types DELEG2 and DS2. Then a delegation that has both = <br>NS and DELEG2 and the query has DE=3D1 then only DELEG2 would be = returned.<br>A delegation with both NS and DS2 (and a DE=3D1 query) = would get both NS and DS2. <br>A delegation with NS, DELEG2, and DS2 = (and a DE=3D1 query) would get DELEG2<br>and = DS2.<br></div></div></blockquote><div><br></div><div>Consider a resolver = understands DS2, but not DELEG2. Since the authoritative server omitted = the NS RRset, the resolver has no delegation information it can actually = use. </div><div><br></div><div>To allow the internet to migrate = from DELEG to DELEG2, operators would therefore need to deploy both = DELEG and DELEG2, each with its own signatures, until DELEG2 is = universally implemented. That seems like a fairly high deployment cost = to preserve a relatively small optimisation in referral = size.</div><div><br></div></div><div><blockquote type=3D"cite"><div><div>I= think that solves the problem. Though at the cost of a bit of = extra<br>complexity. Is there any objection to splitting the = range?<br></div></div></blockquote></div><br><div>I think my proposal = keeps DELEXT itself simpler. Rather than having the generic protocol = decide, based on a type range, whether NS is replaced, each Delegation = Type defines its own interaction with NS. Existing implementations = automatically have a well-defined compatibility behaviour for future = Delegation Types that they do not yet implement.</div><div><p = class=3D"p1">That=E2=80=99s also why I drew the analogy with DNSSEC = algorithm agility. The protocol defines how implementations behave when = they encounter something they don=E2=80=99t yet understand, rather than = requiring future extensions to inherit the semantics of today=E2=80=99s = ones.</p><p class=3D"p1">Roy</p></div></div></body></html>= --Apple-Mail=_CAD314DF-5311-4A52-9ED6-743902122A1E-- --===============8790147304812880456== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============8790147304812880456==--