> 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.
I think cache poinsioning is what the person was trying to get at.
But its kind of a strawman because nobody is suggesting putting unauthenticated keys in dns with no dnssec. The suggestion is either using dnssec, or have some sort of CA system.
> DNSSEC, ... still does not work in most TLD and registers.
I'd be interested to know where you get your data from. By my count, there are 142 ccTLDs that support it and 106 that don't, out of 248 ccTLDs.[0]
That's already more than half, but if you include the gTLDs then the number of TLDs signed in the DNS root goes up to 92% according to the best data I can find.[1]
DNS is only as stale as the cache that you trust. If the cache is not adhering to DNS standards then it is probably not one you should be trusting. Nothing is stopping a DNS client contacting the authoritative nameservers without a cache, or using your own cache that implements the standard correctly.
This is pushing the problem out to an edge that can't really deal with it, i.e. everyone outside a controlled environment. Most people don't know anything about how their DNS cache behaves, and the server-side (where ideally the security posture should be controlled from as much as possible) can't have any influence over it.
If you start using other ways of using DNS, then you might as well not use DNS and instead develop something more suited to the purpose.
2. Cache. People are caching DNS aggressively. Often more aggressive than what the TTL allows.
You don't want to save the fingerprint in a stale, insecure database like that.