[DNSOP] Re: Is DELEXT too restrictive?
Roy Arends <[email protected]> Tue, 28 Jul 2026 21:32:17 +0100
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
--===============0046618494229921613== Content-Type: multipart/alternative; boundary="Apple-Mail=_AF549C93-9C55-4AFB-91A1-74A1F580849D" --Apple-Mail=_AF549C93-9C55-4AFB-91A1-74A1F580849D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jul 2026, at 20:53, John Levine <[email protected]> wrote: >=20 > It appears that Michael Richardson <[email protected]> said: >> (I don't really understand the pushback. I guess I shall re-read = archives) >=20 > It's the usual reason. It adds more complication to DNS servers for > something that has no current use and as likely as not never will. I=E2=80=99m not convinced it adds much complexity. In fact, on the = authoritative server side it arguably simplifies the logic: when DE=3D1, = include the NS RRset and Delegation Types. The server no longer needs to = suppress NS based on the presence of Delegation Types; the interaction = between NS and a particular Delegation Type is defined by that = Delegation Type=E2=80=99s specification and enforced by the resolver. = The resolver already has to implement type-specific processing for = DELEG. > How > are you supposed to test it? I don=E2=80=99t see testing as a significant obstacle. The behaviour is = deterministic and the interoperability matrix is finite. It doesn=E2=80=99= t seem fundamentally different from the behaviours we=E2=80=99re already = specifying and testing. > We're not that short of code points. If at some future time someone > comes up with an actual use for DELEXT+NS, reserve some code points > then. The issue is not code point availability. The interaction between = Delegation Types and NS is currently defined by DELEXT itself, not by = the individual Delegation Type. Once DELEXT implementations are deployed = with the rule that the presence of any Delegation Type causes resolvers = to ignore NS, a future Delegation Type cannot opt out of that behaviour = by obtaining a new RR type code. At that point we=E2=80=99d have to = change DELEXT itself, not just allocate a new Delegation Type. > PS: I don't expect to win this argument since adding cool new features = is much more fun than thinking about how to test and maintain them all. John, I don=E2=80=99t think this is a case of adding a speculative = feature =E2=80=9Cjust in case=E2=80=9D. Rather, it=E2=80=99s about = avoiding hard-coding the semantics of one Delegation Type into a = framework that is explicitly intended to support many future Delegation = Types. If the WG decides that all future Delegation Types should inherit = DELEG=E2=80=99s NS suppressing semantics, that=E2=80=99s a perfectly = valid architectural decision. My point is that we should make that = decision consciously, because it will be difficult to change once DELEXT = is deployed. Roy= --Apple-Mail=_AF549C93-9C55-4AFB-91A1-74A1F580849D 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><div><blockquote type=3D"cite"><div>On= 28 Jul 2026, at 20:53, John Levine <[email protected]> = wrote:</div><br class=3D"Apple-interchange-newline"><div><div>It appears = that Michael Richardson <[email protected]> = said:<br><blockquote type=3D"cite">(I don't really understand the = pushback. I guess I shall re-read archives)<br></blockquote><br>It's the = usual reason. It adds more complication to DNS servers for<br>something = that has no current use and as likely as not never = will.</div></div></blockquote><div><p class=3D"p1">I=E2=80=99m not = convinced it adds much complexity. In fact, on the authoritative server = side it arguably simplifies the logic: when DE=3D1, include the NS RRset = and Delegation Types. The server no longer needs to suppress NS based on = the presence of Delegation Types; the interaction between NS and a = particular Delegation Type is defined by that Delegation Type=E2=80=99s = specification and enforced by the resolver. The resolver already has to = implement type-specific processing for DELEG.</p></div><blockquote = type=3D"cite"><div><div>How<br>are you supposed to test = it?<br></div></div></blockquote><div><br></div><div>I don=E2=80=99t see = testing as a significant obstacle. The behaviour is deterministic and = the interoperability matrix is finite. It doesn=E2=80=99t seem = fundamentally different from the behaviours we=E2=80=99re already = specifying and testing.</div><div><br></div><blockquote = type=3D"cite"><div><div>We're not that short of code points. If at some = future time someone<br>comes up with an actual use for DELEXT+NS, = reserve some code points<br>then. = </div></div></blockquote><div><br></div><div>The issue is not code point = availability. The interaction between Delegation Types and NS is = currently defined by DELEXT itself, not by the individual Delegation = Type. Once DELEXT implementations are deployed with the rule that the = presence of any Delegation Type causes resolvers to ignore NS, a future = Delegation Type cannot opt out of that behaviour by obtaining a new RR = type code. At that point we=E2=80=99d have to change DELEXT itself, not = just allocate a new Delegation = Type.</div><div><br></div><div><blockquote type=3D"cite">PS: I don't = expect to win this argument since adding cool new features is much more = fun than thinking about how to test and maintain them = all.</blockquote><div><br></div><div>John, I don=E2=80=99t think this is = a case of adding a speculative feature =E2=80=9Cjust in case=E2=80=9D. = Rather, it=E2=80=99s about avoiding hard-coding the semantics of one = Delegation Type into a framework that is explicitly intended to support = many future Delegation Types. If the WG decides that all future = Delegation Types should inherit DELEG=E2=80=99s NS suppressing = semantics, that=E2=80=99s a perfectly valid architectural decision. My = point is that we should make that decision consciously, because it will = be difficult to change once DELEXT is deployed.</div><p = class=3D"p1">Roy</p></div></div></body></html>= --Apple-Mail=_AF549C93-9C55-4AFB-91A1-74A1F580849D-- --===============0046618494229921613== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============0046618494229921613==--