[DNSOP] Re: Is DELEXT too restrictive?
Roy Arends <[email protected]> Mon, 3 Aug 2026 23:37:39 +0100
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
--===============6242936814122255622== Content-Type: multipart/alternative; boundary="Apple-Mail=_A708CF86-B19C-45DA-A194-9465BF94192D" --Apple-Mail=_A708CF86-B19C-45DA-A194-9465BF94192D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 John, > On 3 Aug 2026, at 20:46, John Levine <[email protected]> wrote: >=20 > It appears that Philip Homburg <[email protected] = <mailto:[email protected]>> said: >>> In the other direction, if you have a delegation point with only >>> DELEG, and you sent a response to an old non-aware resolver with >>> an authority section that has DELEG and maybe DS and maybe some >>> RRSIGs, will resolvers ignore the useless (to them) stuff and treat >>> it as NODATA, or barf because the authority section has garbage? >>>=20 >>> I have no idea, perhaps people have tried it out. >>>=20 >>> If the answer is NODATA the case for the DE bit is a lot weaker. >>=20 >> There is a problem with DELEG validation. I don't remember all corner = cases, >> but DELEG-unaware validating resolvers may conclude bogus if they = receive >> DELEG records (which they believe is a child-side type) with a = parent-side >> signature. >=20 > If someone knows concretely what the problem is, I'd be interested to = hear about it. > Resolvers check signatures on records they're going to ignore? That = seems odd, > although I suppose it's been a corner case that's not well tested. I don=E2=80=99t recall seeing any evidence that validating resolvers = declared such responses bogus in the absence of the DE flag. The = interoperability testing Shumon and I have done was about whether legacy = resolvers could cope with referrals containing both NS and DELEG (legacy = resolvers could indeed cope). If anyone is aware of tests demonstrating = DNSSEC validation failures without DE, I=E2=80=99d be interested to see = them. 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. I=E2=80=99m happy to be proven otherwise. However, it is independent of = the discussion about DELEXT being too restrictive. Roy= --Apple-Mail=_A708CF86-B19C-45DA-A194-9465BF94192D 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;">John,<br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On 3 Aug 2026, at 20:46, John Levine = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">It appears that Philip Homburg = <</span><a href=3D"mailto:[email protected]" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = orphans: 2; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px;">[email protected]</a><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">> said:</span><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: = solid;"><blockquote type=3D"cite" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: 2; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: = none; text-decoration-thickness: auto; text-decoration-style: = solid;"><blockquote type=3D"cite">In the other direction, if you have a = delegation point with only<br>DELEG, and you sent a response to an old = non-aware resolver with<br>an authority section that has DELEG and maybe = DS and maybe some<br>RRSIGs, will resolvers ignore the useless (to them) = stuff and treat<br>it as NODATA, or barf because the authority section = has garbage?<br><br>I have no idea, perhaps people have tried it = out.<br><br>If the answer is NODATA the case for the DE bit is a lot = weaker.<br></blockquote><br>There is a problem with DELEG validation. I = don't remember all corner cases,<br>but DELEG-unaware validating = resolvers may conclude bogus if they receive<br>DELEG records (which = they believe is a child-side type) with a = parent-side<br>signature.<br></blockquote><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">If someone knows concretely what the = problem is, I'd be interested to hear about it.</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">Resolvers check signatures on records = they're going to ignore? That seems odd,</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">although I suppose it's been a corner case = that's not well tested.</span></div></blockquote></div><div><p = class=3D"p1">I don=E2=80=99t recall seeing any evidence that validating = resolvers declared such responses bogus in the absence of the DE flag. = The interoperability testing Shumon and I have done was about whether = legacy resolvers could cope with referrals containing both NS and DELEG = (legacy resolvers could indeed cope). If anyone is aware of tests = demonstrating DNSSEC validation failures without DE, I=E2=80=99d be = interested to see them.</p><p class=3D"p1">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.</p><p = class=3D"p1">I=E2=80=99m happy to be proven otherwise. However, it is = independent of the discussion about DELEXT being too restrictive.</p><p = class=3D"p1">Roy</p></div></body></html>= --Apple-Mail=_A708CF86-B19C-45DA-A194-9465BF94192D-- --===============6242936814122255622== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============6242936814122255622==--