> You don't want to save the fingerprint in a stale, insecure database like that. I'm trying to figure out how having a stale fingerprint would be an automatic

> You don't want to save the fingerprint in a stale, insecure database like that. I'm trying to figure out how having a stale fingerprint would be an automatic bad thing. Let's assume you have a server with a fingerprint stored in DNS. Something happens and the server's certificate/key needs to change. So now you push out a new key fingerprint to DNS. The failure mode for an out-of-date fingerprint would be to not trust the new server's key. In this case, the default failure mode is to fail safely. The client could then have a few new options, like querying the authoritative DNS server or prompt the user. You can argue that you wouldn't want to have stale DNS caching in an automated system, but in a user-interactive mode, it's not the worst thing. And for an automated system, the system should be robust enough to manage a bad fingerprint (fail safely again), or be in control of the entire infrastructure, including you DNS cache. Or am I missing something?