[DNSOP] Re: Is DELEXT too restrictive?
Roy Arends <[email protected]> Tue, 4 Aug 2026 13:36:35 +0100
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
--===============6440735709125166989== Content-Type: multipart/alternative; boundary="Apple-Mail=_6DCEDAC5-183C-4293-8ACD-04B5AD2F6D53" --Apple-Mail=_6DCEDAC5-183C-4293-8ACD-04B5AD2F6D53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the explanation, Philip! > On 4 Aug 2026, at 13:29, Philip Homburg <[email protected]> = wrote: >=20 >> If anyone >> is aware of tests demonstrating DNSSEC validation failures >> without DE, I'd be interested to see them. >=20 > I tried this a long time ago with a server that would always return = DELEG > records independent of the DE flag. >=20 >> As for DELEG records with a parent-side signature: In absence >> of an NS RRset (and corresponding proof of absence), the legacy >> validating resolver is not aware that it is looking at a delegation >> point. As a result, it does not apply any special delegation >> semantics to the DELEG RRset. Instead, it treats DELEG as an >> unknown authoritative RR type in the responding zone and validates >> its RRSIG in the usual way for an unknown RR type. >>=20 >> I'm happy to be proven otherwise. However, it is independent of >> the discussion about DELEXT being too restrictive. >=20 > Assume a nameserver ns.example.com, it serves two zones, example.com = and > child.example.com. Example.com has delegations to child.example.com = with > both NS and DELEG. Both example.com and child.example.com are DNSSEC = signed. >=20 > A legacy DNSSEC validating resolver is asked to resolve > child.example.com/DELEG. Because it is a legacy resolver it expects to = find > the DELEG record at the apex of child.example.com. It send a query to=20= > ns.example.com because that server is authoritative for = child.example.com. >=20 > ns.example.com is DELEG-aware and responds to the query with the=20 > child.example.com/DELEG RRset as well as the (parent side) signatures. >=20 > The resolver expects signatures from child.example.com and not the > parent-side signatures that it got and concludes bogus. Yes! Thank you for enlightening me, and I stand corrected. You=E2=80=99ve = provided a genuine scenario where the DE flag prevents a validating = resolver from declaring a response bogus. Roy --Apple-Mail=_6DCEDAC5-183C-4293-8ACD-04B5AD2F6D53 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;"><p style=3D"margin: 0px; font-width: = normal; font-size: 13px; line-height: normal; font-size-adjust: none; = font-kerning: auto; font-variant-alternates: normal; = font-variant-ligatures: normal; font-variant-numeric: normal; = font-variant-east-asian: normal; font-variant-position: normal; = font-feature-settings: normal; font-optical-sizing: auto; = font-variation-settings: normal;">Thanks for the explanation, = Philip!</p><div><br><blockquote type=3D"cite"><div>On 4 Aug 2026, at = 13:29, Philip Homburg <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div><blockquote type=3D"cite"> = If anyone<br> is aware of tests demonstrating = DNSSEC validation failures<br> without DE, I'd be interested = to see them.<br></blockquote><br>I tried this a long time ago with a = server that would always return DELEG<br>records independent of the DE = flag.<br><br><blockquote type=3D"cite"> As for DELEG records = with a parent-side signature: In absence<br> of an NS RRset = (and corresponding proof of absence), the legacy<br> = validating resolver is not aware that it is looking at a = delegation<br> point. As a result, it does not apply any = special delegation<br> semantics to the DELEG RRset. = Instead, it treats DELEG as an<br> unknown authoritative RR = type in the responding zone and validates<br> its RRSIG in = the usual way for an unknown RR type.<br><br> I'm happy to = be proven otherwise. However, it is independent of<br> the = discussion about DELEXT being too = restrictive.<br></blockquote><br>Assume a nameserver ns.example.com, it = serves two zones, example.com and<br>child.example.com. Example.com has = delegations to child.example.com with<br>both NS and DELEG. Both = example.com and child.example.com are DNSSEC signed.<br><br>A legacy = DNSSEC validating resolver is asked to = resolve<br>child.example.com/DELEG. Because it is a legacy resolver it = expects to find<br>the DELEG record at the apex of child.example.com. It = send a query to <br>ns.example.com because that server is authoritative = for child.example.com.<br><br>ns.example.com is DELEG-aware and responds = to the query with the <br>child.example.com/DELEG RRset as well as the = (parent side) signatures.<br><br>The resolver expects signatures from = child.example.com and not the<br>parent-side signatures that it got and = concludes bogus.<br></div></div></blockquote><br></div><div>Yes! Thank = you for enlightening me, and I stand corrected. You=E2=80=99ve provided = a genuine scenario where the DE flag prevents a validating resolver from = declaring a response = bogus.</div><div><br></div><div>Roy</div><br></body></html>= --Apple-Mail=_6DCEDAC5-183C-4293-8ACD-04B5AD2F6D53-- --===============6440735709125166989== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============6440735709125166989==--