Difference in validating behavior 9.18 / 9.20

[John Thurston]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250210/186bdc63/attachment.htm>