Ask Slashdot: Could We Not Use DNS For a Certificate Revocation Mechanism?

Long-time Slashdot reader dhammabum writes: As reported in the recent slashdot story, starting in September we system admins will be forced into annually updating TLS certificates because of a decision by Apple, abetted by Google and Mozilla. Supposedly this measure somewhat rectifies the current ineffective certificate revocation list system by limiting the use of compromised certificates to one year… But in an attempt to prevent this pathetic measure, could we instead use DNS to replace the current certificate revocation list system? Why not create a new type of TXT record, call it CRR (Certificate Revocation Record), that would consist of the Serial Number (or Subject Key ID or thumbprint) of the certificate. On TLS connection to a website, the browser does a DNS query for a CRR for the Common Name of the certificate. If the number/key/thumbprint matches, reject the connection. This way the onus is on the domain owner to directly control their fate. The only problem I can see with this is if there are numerous certificate Alternate Names — there would need to be a CRR for each name. A pain, but one only borne by the hapless domain owner. Alternatively, if Apple is so determined to save us from ourselves, why don’t they fund and host a functional CRL system? They have enough money. End users could create a CRL request via their certificate authority who would then create the signed record and forward it to this grand scheme. Otherwise, are there any other ideas?