<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Comparing the ARM for <a href="https://bind9.readthedocs.io/en/bind-9.18/dnssec-guide.html#bind-dnssec-debug-logging">9.18</a>
and 9.20, I see the same text in both regarding time, RRSIG, and
validity</p>
<p>
<blockquote type="cite">In DNSSEC, every record comes with at
least one RRSIG, and each RRSIG
contains two timestamps: one indicating when it becomes valid,
and
one when it expires. If the validating resolver’s current system
time does
not fall within the two RRSIG timestamps, error messages
appear in the BIND debug log.</blockquote>
</p>
<p>And both 9.18 and 9.20 log the described error message (i.e
"verify failed . . RRSIG has expired"), but the 9.18 server goes
on to log a failure message (i.e. "no valid signature found") and
the 9.20 server returns a validated answer with no errors logged.<br>
</p>
<p>If I understand the merge-flow, issue #4586 says an expired RRSIG
can be ignored when validating if there is a valid RRSIG which
will do the job. And that this behavior was incorporated into 9.18
with release .27 Which means the ARM is incomplete. BIND <i>does</i>
log an error message when it discovers the expired RRSIG, but the
validation does not necessarily fail with this discovery (which I
feel is implied in the ARM).</p>
<p>And that isn't the behavior we were seeing yesterday with
9.18.31/33 :( Yes, cdc.gov corrected their RRSIG records, so
validation succeeds again, but I really need to understand why our
9.18 and 9.20 servers behaved differently. We have reasons to be
running some 9.18 and some 9.20, but if the two are going to
behave so differently when validating responses we will need to
re-visit that decision.<br>
</p>
<p>Right now, the only way I can think to nail down this behavior is
to:</p>
<ul>
<li>delegate a subdomain to myself</li>
<li>sign it</li>
<li>intentionally publish an expired RRSIG in it</li>
</ul>
<p>Which makes my next question:</p>
<p> Will BIND even let me do this? Or will it the automation rake
out the expired records and refuse to serve them</p>
<br>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 2/7/2025 10:56 AM, Darren Ankney
wrote:<span style="white-space: pre-wrap">
</span></div>
<blockquote type="cite" cite="mid:CAKabWHhOBUnN4J4CqACZ2FrXow9sLXHmUiT_25+t20yG9K4bfQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi John,
About the release note you mention with the [GL #4586], this indicates
the Gitlab issue that was fixed and resulted in this release note.
. . .
I was going to test but it seems that the expired RRSIG was removed
from transfer3.rastglb.cdc.gov
Thank you,
Darren Ankney
On Thu, Feb 6, 2025 at 8:49 PM John Thurston <a class="moz-txt-link-rfc2396E" href="mailto:john.thurston@alaska.gov"><john.thurston@alaska.gov></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
We run both 9.18 and 9.20. We currently have servers running:
9.18.31
9.18.33
9.20.3
9.20.5
The 9.18 and 9.20 validating resolvers behave differently when exposed to expired RRSIG records.
Both versions log errors of the type
validating transfer3.rastglb.cdc.gov/A: verify failed due to bad signature (keyid=13215): RRSIG has expired
but 9.18 goes on to log
validating transfer3.rastglb.cdc.gov/A: no valid signature found
and returns a SERVFAIL
9.20 returns a fully validated response.
Both servers will return the same set of records (9.18 must be queried with the +cd flag) when asked:
transfer3.rastglb.cdc.gov. 5 IN A 198.246.125.128
transfer3.rastglb.cdc.gov. 5 IN RRSIG A 5 4 5 20250126201505 20241028201505 13215 rastglb.cdc.gov. Kx+n+gsnq0BSko0tl/B3HftLDp1XtiIyImBnlE/dAWgv8VD8xwq4bPns CO1R3k3beerK1UB/OpP9VKViRnN+3E4S5fg9vpZOFsDXB4T7PmDg5N12 PwN26IJC8BrvUnqkPFdYEJGzb+orKHZsa949shODtnAVkttC4NsYvIRq MR8=
transfer3.rastglb.cdc.gov. 5 IN RRSIG A 8 4 5 20250309140556 20241209140556 43989 rastglb.cdc.gov. XSLHv9vpeY9O0JdfxPzIrkJjU8CkfioV4S0dorRK6GL8DLHjqwpyyM1k km2MjF/2lXMjAl+D4+QrNhQFfDo50njTbSKfDsDSWUZC/QffESlw6t6x XdCrShtJ6YVYltK1FgWf5xOepxEFLw0pn7I2ntDmXVLwsNkapdKqGugt vzc=
But 9.18 appears to stumble, and consider the presence of 13215 to be the end of the validation-road.
I found this in the release notes
--- 9.18.27 released ---
6374. [bug] Skip to next RRSIG if signature has expired or is in
the future rather than failing immediately. [GL #4586]
But I'm not sure how to interpret it. Is it saying that GL#4586 has left a bug, and should be corrected as described? or is it describing the behavior we should see in versions >= 9.18.27 ?
</pre>
</blockquote>
</blockquote>
</body>
</html>