Difference in validating behavior 9.18 / 9.20

[John Thurston]

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.Thurston at 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.thurston at 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 ?
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250207/b605005c/attachment-0001.htm>