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.
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. 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. Maybe 'updated' would be better? On Thu, Feb 27, 2025 at 10:07 AM Warren Kumari <war...@kumari.net> wrote: > > On Wed, Feb 26, 2025 at 7:47 PM, George Michaelson <g...@algebras.org> > wrote: > >> 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. >> >> I think the record itself structurally is fine. But the operational duty >> cycle over it, is probably not adequately integrated into systems. >> > > Yeah, that was Jan-Piet Mens' facts2sshfp ( > https://github.com/jpmens/facts2sshfp) 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. > > 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. > > In theory this should be sim… Oh, actually it looks like Jan-Piet has > already done this as well: > https://jpmens.net/2012/11/03/an-action-plugin-for-ansible-to-handle-ssh-host-keys/ > > W > > > "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. >> >> -G >> >> _______________________________________________ >> dns-operations mailing list >> dns-operations@lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> > > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations >
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
