Comparing the ARM for 9.18
<https://bind9.readthedocs.io/en/bind-9.18/dnssec-guide.html#bind-dnssec-debug-logging>
and 9.20, I see the same text in both regarding time, RRSIG, and validity
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.
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.
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 /does/ 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).
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.
Right now, the only way I can think to nail down this behavior is to:
* delegate a subdomain to myself
* sign it
* intentionally publish an expired RRSIG in it
Which makes my next question:
Will BIND even let me do this? Or will it the automation rake out
the expired records and refuse to serve them
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
On 2/7/2025 10:56 AM, Darren Ankney wrote:
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<john.thurs...@alaska.gov> wrote:
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 ?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users