Set up CNAME to cloudflare-ipfs.com when one doesn't exist

[agentofuser]

When deploying a new website using the Cloudflare DNS, ipfs-deploy --dns cloudflare sets the _dnslink TXT record, but not the CNAME.

This means that accessing the new website from an IPFS gateway (local or public) works, but going to the domain's dnslinked address directly results in a DNS error.

By default, ipfs-deploy opens the browser to this new dnslinked address right after pinning it and creating the _dnslink record, so it's confusing/jarring to get an error screen from the browser when everything actually worked fine.

One solution would be to automatically set up the CNAME record as well (if it doesn't yet exist), changing the behavior of the --dns flag.

If making the distinction more explicit is desired, the --dns flag could be deprecated (but keep working for now) and two separate flags, like --dnslink and --cname could be created, though I'm not sure the added cognitive load is worth it.

[Macil]

I personally wouldn't expect the tool to do first-time setup like this on the same command that's used for routinely updating the dnslink record. If I hadn't seen this thread, I could imagine this having bit me soon because I'm planning on switching my domain away from being CNAMEd as cloudflare-ipfs.com to my own server which similarly serves from ipfs using the dnslink but also adds some niceties like HTTPS redirect, HSTS, and more specific caching headers.

[agentofuser]

@Macil that's a good point. Thanks for adding that usecase. So if I understand correctly you're still going to use Cloudflare for the TXT _dnslink record but point the CNAME (still using Cloudflare name servers) to your own server?

[Macil]

Right. (Well it most likely wouldn't be a CNAME, but just A/AAAA root records pointing to my server.)