<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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<br>
</p>
<p><font face="monospace">z.ak.gov. IN NS ns88.state.ak.us</font></p>
<p>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:</p>
<p><font face="monospace">zone "z.ak.gov" { type primary; file
"z.ak.gov"; };</font></p>
<p>and confirmed my delegation worked, and that it would answer
correctly.</p>
<p>Then I added " <font face="monospace">dnssec-policy default;
inline-signing yes;</font>" to my zone statement, reloaded the
zone, and used <font face="monospace">rndc dnssec -status
z.ak.gov</font> to see that it was happy. I could still dig the
records I had entered. If I added <font face="monospace">+dnssec</font>
to my <i>dig</i> I saw the RRSIG record. If I used <i>delv</i> I
would get an 'unsigned answer'. If I used <i>delv</i>, and made
it reference an anchor-file of my own making</p>
<p><font face="monospace">delv @ns88.state.ak.us -a ./z.ak.gov.key
+root=z.ak.gov. z.ak.gov. SOA</font></p>
<p>I could get a fully-validated answer. Yay!!</p>
<p>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).</p>
<p>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</p>
<ul>
<li>switch to manual signing</li>
<li>define a long TTL for my zone</li>
<li>sign the zone with a key with a short longevity</li>
<li>get the long TTL RRSIGs cached in my resolvers</li>
<li>after RRSIG is invalid, shorten the TTL on the zone</li>
<li>re-sign the zone</li>
<li>find both the new and the old RRSIG in my resolvers</li>
</ul>
<p>Is there a simpler way to force an expired RRSIG into a
response-set?<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 2/7/2025 12:50 PM, John Thurston
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1f067362-6855-4d55-afc6-aa5fd7793a75@alaska.gov">
<p>Right now, the only way I can think to nail down this behavior
is to:</p>
<ul>
<li>delegate a subdomain to myself</li>
<li>sign it</li>
<li>intentionally publish an expired RRSIG in it</li>
</ul>
<p>Which makes my next question:</p>
<p> Will BIND even let me do this? Or will it the automation
rake out the expired records and refuse to serve them</p>
</blockquote>
</body>
</html>