Open agentofuser opened 4 years ago
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.
@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?
Right. (Well it most likely wouldn't be a CNAME, but just A/AAAA root records pointing to my server.)
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.