We have a client who insisted on using a .house domain. It kept triggering alerts on our uptime monitoring service with DNS errors, so we had to reduce the sensitivity of that specific test. 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 syst…
> I still advise clients to use www rather than a plain domain name for websites And you should. Not only can’t you put CNAME at the zone APEX without doing nasty tricks but not doing so is also a security risk when dealing with cookies.
Benchmarking DNS response times of TLDs
31–40 of 141 posts
Re: Benchmarking DNS response times of TLDs
#32A little off topic, but some of you folks have experience with bunnycdn, the company behind the post? Are they fine?
https://reddit.com/r/SideProject/comments/419hz0/bunnycdn_th...
Re: Benchmarking DNS response times of TLDs
#33Earlier quoted context omitted.
Although I may see what the BunnyCDN is trying to get at, personally I've gotten under 10ms with .com (even w/o caching). I find this a bit hard to believe without more people justifying or backing this work up. So yeah, don't worry about your TLD. .io is perfectly fine and companies and people internationally use it.
.io doesn't have a good history though outside of this - https://hn.algolia.com/?query=io%20domain&sort=byPopularity&...
https://gigaom.com/2014/06/30/the-dark-side-of-io-how-the-u-...
Re: Benchmarking DNS response times of TLDs
#34Earlier quoted context omitted.
> I still advise clients to use www rather than a plain domain name for websites And you should. Not only can’t you put CNAME at the zone APEX without doing nasty tricks but not doing so is also a security risk when dealing with cookies.
Could you (or someone) explain this? (I'm not arguing, I'm interested.)
Re: Benchmarking DNS response times of TLDs
#35Would 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.
Re: Benchmarking DNS response times of TLDs
#36Earlier quoted context omitted.
> I still advise clients to use www rather than a plain domain name for websites And you should. Not only can’t you put CNAME at the zone APEX without doing nasty tricks but not doing so is also a security risk when dealing with cookies.
Could you (or someone) explain this? (I'm not arguing, I'm interested.)
If you had records such as:
@ IN A 127.0.0.1
@ IN CNAME example.org.
The server could not answer anything sensible as you now just introduced an ambiguity.
The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly:
- Given a record `@ IN ALIAS example.org.`.
- Pull records at `example.org` (maybe with an AXFR request but usually just individual records).
- Merge our domain APEX with `example.org` records we just pulled.
- Reply to requester with the merged zone, discarding the ALIAS record.
Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.
Re: Benchmarking DNS response times of TLDs
#37Earlier quoted context omitted.
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.
I blacklist .xyz, .ninja, and a few others. Nobody complains.
Re: Benchmarking DNS response times of TLDs
#38Earlier quoted context omitted.
I humbly suggest this is not a good use of your time.
nope I would kill to be able to cut 50ms by DNS tweaks across the large fleet >100 sites for a major brand
Oh, and if the requestor has a large DNS cache upstream, it's already done.
Oh, and if the browser used a pre-fetch, that's already done.
Oh, and if you have already invested your branding effort across 100 sites, maybe you don't want to re-do all that?
Oh, and if you need to cut 50ms from your first time page load, have you considered dropping all the trackers and analysis JS loads? Can you deliver your first page without any JS at all? Can you do it without a database lookup?
Those are all things you should do before killing anyone.
Re: Benchmarking DNS response times of TLDs
#39Re: Benchmarking DNS response times of TLDs
#40We have a client who insisted on using a .house domain. It kept triggering alerts on our uptime monitoring service with DNS errors, so we had to reduce the sensitivity of that specific test. 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 syst…
not suprising at all, I've seen e-mail address validation code that (among other things) used a fixed list of TLDs. I could imagine some spam filters doing a similiar thing.