Difference in validating behavior 9.18 / 9.20

[Mark Andrews]

If you want to test behaviour with expired records you are going to need to use dnssec-signzone.
The tests that ship with BIND use dnssec-signzone to build zones with out of date signatures.

As for dnssec-policy it is not designed to produce broken zones.

Mark

> On 11 Feb 2025, at 10:18, John Thurston <john.thurston at alaska.gov> wrote:
> 
> Trying to kick this football, I delegated a zone (z.ak.gov) to one of my test servers, by adding a record to ak.gov
> z.ak.gov. IN NS ns88.state.ak.us
> And on the ns88 server, I created a zone file with an SOA, NS, A, and a TXT record. I defined it with a basic zone-statement:
> zone "z.ak.gov" { type primary; file "z.ak.gov"; };
> and confirmed my delegation worked, and that it would answer correctly.
> Then I added " dnssec-policy default; inline-signing yes;" to my zone statement, reloaded the zone, and used rndc dnssec -status z.ak.gov to see that it was happy. I could still dig the records I had entered. If I added +dnssec to my dig I saw the RRSIG record. If I used delv I would get an 'unsigned answer'. If I used delv, and made it reference an anchor-file of my own making
> delv @ns88.state.ak.us -a ./z.ak.gov.key +root=z.ak.gov. z.ak.gov. SOA
> I could get a fully-validated answer. Yay!!
> The zone ak.gov is not signed, so while I could publish a DS-record there, I suspect delv won't accept it while performing its validation work. I expect that naming my .key file as an anchor is just as good as letting delv find a validated DS record in a.gov (for the purposes of learning how 9.18 and 9.20 validating resolvers differ).
> But now I think I'm stuck. I think the default dnssec-policy isn't going to let me force a re-signing in a way which will leave expired RRSIG records behind (which is what I'm trying to test). I suspect I'm going to have to
>     • switch to manual signing
>     • define a long TTL for my zone
>     • sign the zone with a key with a short longevity
>     • get the long TTL RRSIGs cached in my resolvers
>     • after RRSIG is invalid, shorten the TTL on the zone
>     • re-sign the zone
>     • find both the new and the old RRSIG in my resolvers
> Is there a simpler way to force an expired RRSIG into a response-set?
> 
> --
> 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 12:50 PM, John Thurston wrote:
>> 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
> -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org