The majority of dnslink entries you found are for /ipns/ addresses, which doesn’t surprise me at all that they won’t resolve due to the requirement of having the publishing node remain online. I think there’s a reason that Protocol Labs’ websites all currently point to /ipfs/ paths (at least, indirectly) rather than /ipns/ ones. And I think that reason is that IPNS currently has some issues specific to IPNS. IPFS in general is self-admittedly still under heavy development and not production-ready (according to their github repo) which also doesn’t lend itself to widespread production use at this point.
If we look at the /ipfs/ paths (or /ipns/ paths that point to another domain which points to an /ipfs/ path) the success rate is 50% (possibly a bit lower if we consider that even if the parent hash is available the entire site might not be). I’d tend to attribute the low success rate even for these paths to people using IPFS as something to play around with or test with rather than something that’s their primary deployment platform – and so don’t bother to make sure it’s available. The other factor is that people accessing these sites are likely not using IPFS at all to access the sites which doesn’t help with availability. Browsers don’t ship with IPFS support so the number of people actually using the dnslinks to resolve and cache the site as they browse is probably very low.
resolves, alexa rank, domain, dnslink records
yes, #17495, ipfs.io, "/ipns/website.ipfs.io"
no, #55588, avsim.su, "/ipfs/Qmc2UTyFv4qD4LDRAAoMnSRiQMNy63t5wUgq9Y83YmUJuJ"
yes, #235414, _dnslink.dallasmakerspace.org, "/ipfs/QmcgHMhAzAqZpQUnarDhqA8XhAbYuHuixkUH2r5T8S9YtP/"
yes, #379024, _dnslink.filecoin.io, "/ipns/website.filecoin.io"
no, #409990, originprotocol.com, "/ipfs/QmcFM7wh7KwEsRZWFG5dyV1kmbBgUSZwiYeSScPErKysVS"
no, #758417, peej.co.uk, "/ipfs/QmaBEAir6UE8JHb2wk2EgQeK2gbcJ4JChRbC9k8n13M4sx"