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

Reply via email to