DNS for authentication of ownership, and orphanage

There ‘s a reasonably large use of DNS for things other than ‘Doman Name Serving’. The use of TXT records (SPF, DKIM, Let’s Encrypt, …) is widespread (as is CNAMES etc) for purposes other than ‘resolving a host’. For example, if you bring your own domain to Google G-Suite, you demonstrate you own it by putting a specific record in.

I postulate that these records never get deleted, and get forgotten. I know mine do 🙂

Now, a few extra TXT records doesn’t make a ton of difference. Maybe a zone-transfer is bigger, a few bytes here and there.

But what about other record types? Like a CNAME? These are used with Amazon Cloudfront, Azure CDN, Cloudflare, etc. And this means that if you have a CNAME in your file, and it points to someone else, you should make sure you own that other foreign destination, or remove the CNAME if you no longer do.

This article talks a bit about the perils of this on Cloudfront. Essentially, you cancel your use of Cloudfront for a host, and some squatter gets in and takes it. And now they have something that honest-to-god resolves through your authoritative DNS to that destination. Which means they could sign an SSL certificate for it with host-challenge methods.

And, cuz its 2018, there’s a Github repo with more examples.

Now, is this a big problem? If so, what is the solution? DNS is not a double-indexed database where you can check dangling forward or backward links. Its probably a (medium?) issue for organisations with a dynamic DevOps environment, cruft accumulates over time, and, well, like cockroaches, the baddies find a way in.

PS, got $127K, and want some minor (in)famy? Squat this!

Now, go forth and check thy CNAME’s. let not some forgotten experiment risk thy cloud, its in the commandments, somewhere near the end.