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.thurs...@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.thurs...@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@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: ma...@isc.org
--
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
