this doesn't eliminate fraudulent ssl certificates, just reduces the possibility of them occurring by reducing the amount of parties involved (eg someone asks the ".com" provider to delegate the domain to them and they just mirror your records with slight modifications)
there could also be issues with caching, i have seen more than one ISP modify dns headers and change the TTL value to 3+ days which caused havoc with site migrations. munging of the TTL field could cause time delays with revoking certs
the anti malware guys really don't like it when you delay for any reason.
i already use the SSHFP record to indicate which ssh keys are valid for a host and it works well but in conjunction with my standard known hosts file (in revision control to make it easy to move out to new hosts and keep track of things)
personally i think the dns records combined with other methods eg a local list of certs watching for changes and checking with a distributed table of sites => certs is the best option. however i would hate to see the conflict resolution code should one and not all of these comes back with an "invalid cert"
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds