<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Warren's bitrot issue is a common issue with policy records, there is a tendency for the DNS policy statement to be updated for a limited period of time.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What if there was a 'expiry' date on policy records? Doesn't have to have great precision, year/month/day would be sufficient. Just drop it into the policy TXT record just like anything other tag/value pair.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Not necessarily something to enforce in relying parties. But would be useful to be able to look at a zone and see that there are supposedly automated records haven't been updated for 2 years.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Maybe 'updated' would be better?</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2025 at 10:07 AM Warren Kumari <<a href="mailto:warren@kumari.net">warren@kumari.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><div><div><div class="gmail_signature"><br></div></div></div><div><div><div class="gmail_quote">On Wed, Feb 26, 2025 at 7:47 PM, George Michaelson <span dir="ltr"><<a href="mailto:ggm@algebras.org" target="_blank">ggm@algebras.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div dir="ltr"><div dir="ltr">In the same spirit, I know a group using them but they're so prone to bitrot, from OS upgrade, which with virtuals is a low cost operation and mostly avoids issues for the real job of the machine: individuals keying info is in their home states which copy in from other places, but the SSHFP information is recreated in the new VM build, and then nobody remembers to update the central view.<div><br></div><div>I think the record itself structurally is fine. But the operational duty cycle over it, is probably not adequately integrated into systems. <br></div></div></div></div></div></blockquote></div></div></div></div><div><div><br></div><div>Yeah, that was Jan-Piet Mens' facts2sshfp (<a href="https://github.com/jpmens/facts2sshfp" target="_blank">https://github.com/jpmens/facts2sshfp</a>) was intending to solve. When I used Puppet for my system-admin stuff this worked nicely. Puppet would know about all of my machines, and would automagically update my SSHFP records. <br></div><div><br></div><div>However, I was unable (well, unwilling) to deal with the number of breaking changes to Puppet's syntax, and so I migrated to Ansible instead, and never re-integrated this into my workflow. <br></div><div><br></div><div>In theory this should be sim… Oh, actually it looks like Jan-Piet has already done this as well: <a href="https://jpmens.net/2012/11/03/an-action-plugin-for-ansible-to-handle-ssh-host-keys/" target="_blank">https://jpmens.net/2012/11/03/an-action-plugin-for-ansible-to-handle-ssh-host-keys/</a><br></div><div><br></div><div>W</div><div><br></div><div><br></div></div><div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div>"Don't forget to update your SSHFP record for this host" or "I am re-using the host SSHID information you copied into my install process" type stories would help.<br></div><div><br></div><div>-G<br></div></div></div>

<p>_______________________________________________
<br>
dns-operations mailing list
<br>
<a rel="noopener noreferrer" href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a>
<br>
<a rel="noopener noreferrer" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a></p></div></div></blockquote></div></div></div></div><div><br></div></div><div></div></div></div>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>