Recently, I started buying non .com domain names here and there when I see a keyword that I think well-matches the extension. I’m not interested in sharing specifics with you, but I have bought .AI, .IO, .CO, .APP, and .DEV domain names in auction, in addition to .XYZ that I previously wrote about. Non .com domain names is a small percentage of my portfolio and a fraction of a percentage of inventory cost.
One word of caution is that some extensions have rules that need to be followed in order to use the domain name. I learned this after winning a .Dev domain name in auction at Namecheap. A day or two after setting the nameservers to Afternic, the domain name did not resolve to a landing page. I checked in with Afternic and the domain name was set up correctly there. I submitted a ticket at Namecheap to see what was preventing the domain name from resolving, and here’s what I was told:
“Per our check, the [redacted].dev domain is pointing to the DNS servers of Afternic and indeed having an issue with its SSL protection. According to the requirements by Google Registry, all .DEV websites should have an SSL certificate installed along with the HTTPS setup for them to load in browsers.
If Afternic or the actual hosting vendor connected to the domain offers free SSL certificates for your subscription with them, please ask them to set up the certificate on the domain. If they do not offer their own SSL but support third-party SSL service, you can also purchase a certificate from us to have it installed to the domain by your hosting provider”
Whoops. This may have been something I should have known about before winning the auction, but it’s a good lesson for me. If I want this domain name to resolve to a landing page – even if I want to forward it somewhere – I am going to have to take additional steps beyond what I normally do.
I still haven’t decided how I am going to proceed with this. Perhaps I will set up a Carrd inquiry form for this and potentially other domain names with similar requirements. Even if I don’t get this and any other names to resolve, they will be listed for sale via Afternic.
Same applies to all Registry.Google newTLDs. You can also check in Chrome Query HSTS/PKP domain and it shall show:
[blockquote]static_upgrade_mode: FORCE_HTTPS[/blockquote]
so .PAGE etcetera
This is specifically called HSTS preloading. Several new TLDs are in the HSTS preload list. This is a good thing: all websites should be using TLS (not SSL–that’s a bit of a misnomer), and there’s really no reason you wouldn’t want to use it. Hopefully, more and more TLDs will find their way into the HSTS preload list.
Even if your TLD isn’t HSTS-preloaded, you should consider adding any developed websites to the HSTS preload list: https://hstspreload.org You may want to avoid doing this for domains you intend to sell, as some potential buyers might not yet be ready for HSTS, and it takes a while–on the order of years–to undo HSTS preloading.
If your domain landing pages don’t support TLS, many users won’t be able to access them or will receive a scary warning from their browser when they attempt to do so. The error will be similar to what you saw when you had a .dev domain that didn’t support TLS. Consider this a good litmus test: if your .dev domain doesn’t work with your parking provider, then it’s time to put pressure on your parking provider to modernize.
When NamePros developed its parking solution, this was one of the biggest hurdles we faced. Our beta testers indicated that a parking solution without TLS support was a no-go. If your domain doesn’t support TLS, you’re losing out on leads. If an entire parking provider doesn’t want to support TLS, well… that says a lot about their plans (or lack thereof) for the future–it might be time to start migrating to an alternative.
That is a nice explanation Paul thank you for sharing all this.