11–20 of 141 posts
Edit: I see what they did. They picked a random nameserver for each TLD. This means that those using only anycast servers win as they always hit the same POP. .org uses only some anycast instances.
It pretty much outperforms .com/.net/.org
#MakeInIndia
> For each top-level domain, our system picked a random nameserver published for each of the top-level domains and queried a random domain name that we picked for it. We then grouped the results by region and logged the data every 10 seconds. Am I misunderstanding what they're doing or is this completely misleading? If they're only testing one randomly chosen nameserver, the results are much less likely to be a good…
In other words, what they wrote suggests it’s not just one fixed nameserver chosen per TLD, rather randomly chosen each time they will make a request.
This is one of those things you simply don't expect to test when you're benchmarking performance. I've been trying to cut away chunks of 20-50ms on a side project I've been working on hosted on a .io domain, and I'm seriously considering switching because of this. Great article for sure. I also wonder at what point the trade off is between a vanity domain vs a more performant domain. For a CDN this makes perfect sens…
I humbly suggest this is not a good use of your time.
But I agree one needs to zoom out and put things into its proper perspective.
Would love to hear if the same applies to SEO and/or spam filters. I have a .works domain, which looks nice, but it was a huge mistake and wish I had gone for a .com: - people often mispell it to .work, or just generally get confused - one customer actually couldn't receive my emails because some layer in their email stack was blocking this domain - .work exists, and somebody else owns [name].work, which is a potenti…
I’ve heard anecdotally that getting .xyz email delivered is much harder than .com, some servers just blanket reject. I expect this will change as the domains become more popular.
We also had a client who had to change their TLD from .healthcare to .org.uk because (a) people were confused because they didn't understand that there are all these new TLDs and kept adding .co.uk, .org etc and (b) some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare, saying that it was a malformed email address.
I think in the vast majority of cases these new TLDs aren't worth it until the general population's understanding catches up. I still advise clients to use www rather than a plain domain name for websites, because I've come across a significant minority of people who need that "www" as a clear signal that it's a website.
Are they fine?
Would love to hear if the same applies to SEO and/or spam filters. I have a .works domain, which looks nice, but it was a huge mistake and wish I had gone for a .com: - people often mispell it to .work, or just generally get confused - one customer actually couldn't receive my emails because some layer in their email stack was blocking this domain - .work exists, and somebody else owns [name].work, which is a potenti…
I’ve heard anecdotally that getting .xyz email delivered is much harder than .com, some servers just blanket reject. I expect this will change as the domains become more popular.
This is one of those things you simply don't expect to test when you're benchmarking performance. I've been trying to cut away chunks of 20-50ms on a side project I've been working on hosted on a .io domain, and I'm seriously considering switching because of this. Great article for sure. I also wonder at what point the trade off is between a vanity domain vs a more performant domain. For a CDN this makes perfect sens…
I'd say the inverse is more likely. If you're going to fire a single request to a domain only you are using and you're running a full local resolver, it may make a difference.
For a public CDN: your browser already has the file cached. If it doesn't then it has the domain cached. If it doesn't then the dhcp-provided resolver has it. If it doesn't, then at least it already has the TLD nameserver available immediately, and the TLD can serve that response from very hot cache. It's CDNs job to make sure this happens.
This is one of those things you simply don't expect to test when you're benchmarking performance. I've been trying to cut away chunks of 20-50ms on a side project I've been working on hosted on a .io domain, and I'm seriously considering switching because of this. Great article for sure. I also wonder at what point the trade off is between a vanity domain vs a more performant domain. For a CDN this makes perfect sens…
I humbly suggest this is not a good use of your time.