
Benchmarking DNS response times of TLDs - twapi
https://bunnycdn.com/blog/is-your-fancy-new-domain-hurting-your-performance-gtld-benchmark/
======
frereubu
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 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.

~~~
Eikon
> 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.

~~~
SiVal
Could you (or someone) explain this? (I'm not arguing, I'm interested.)

~~~
Eikon
You can only put CNAME records at the zone APEX if there is no other records
kinds as a CNAME is supposed to be a synonymous.

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`.

~~~
867-5309
unless I am hosting separate sites/IPs on subdomains, or have a complex cookie
situation, I think the www. prefix seems vestigial/legacy and completely
unneeded. I am actually in the opposite camp of not including it at all and
redirecting to non-www. it sounds awfully ambiguous in speech ("double-u
double-u double-u dot", "all the double-us dot", "dub dub dub dot", etc.) and
most times multiplies the syllabic length of a "catchy" address. I even had an
older client who said "stop" instead of "dot", and another who used @www. in
an email address. I also think it looks silly and unprofessional on business
cards, on the side of vans, etc., especially when [http://](http://) and/or a
trailing fowardslash is also included _cringe_. if it MUST exist, DNS does not
always have to be involved, it could just be a simple http 301 forward or
vhost config. we don't add :80 or :443 to the end of a web address. let the
browser handle all that.

~~~
gregmac
It's worth making it exist and doing a 301 redirect. There's some people that
will still type it, and others that will link it without checking, and they'll
just think your site is broken. You're fighting against the grain for what's
essentially a couple lines of config.

It's not much different than using TLS for everything, but still handling and
redirecting [http://](http://) traffic (also doing a 301 redirect).

~~~
toast0
It's also useful to set hsts for the whole domain.

I'm opinionated enough to say if you type
[http://example.org/foo](http://example.org/foo), I'm just going to redirect
that to [https://www.example.org/](https://www.example.org/) but reasonable
people could disagree (especially since Chrome has been going back and forth
on displaying the actual URL and something that's vaguely similar to it)

~~~
otterlicious
That would just be a giant middle finger to people who manually type URLs.

------
random_savv
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 potential
security risk...

~~~
danpalmer
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.

~~~
dsr_
I blacklist .xyz, .ninja, and a few others. Nobody complains.

~~~
grose
I had to blacklist .top and .xyz registrations for a free service because they
were being used exclusively for spam. xyz in particular I think is just so
cheap (often $0.99 to $2) that it's tempting for spammers to register a bunch
of throwaway domains.

------
jjcm
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 sense, but would it be better to launch
with a less-notable url vs a more performant one?

~~~
recuter
I humbly suggest this is not a good use of your time.

~~~
C1sc0cat
nope I would kill to be able to cut 50ms by DNS tweaks across the large fleet
>100 sites for a major brand

~~~
Ayesh
If you haven't done already, take a look at don't delivery improvements. Serve
don't files locally, subset them, and use variable fonts and woff2. I'm a
micro performance enthusiast myself and it's my #1 optimization with the
biggest gain.

~~~
C1sc0cat
dont't ??

I will have a look at your font suggestions

------
cotillion
I don't think you can draw any conclusions at all from this. They appear to
have measured how far it is from their CDN pops to the anycast instances of
the TLDs.

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.

------
bscphil
> 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 indication of the speed of an average request for that
TLD. Why not average across all of them?

Also, as they kind of suggest near the end, caching is probably good enough
that this is very rarely a problem anyone needs to worry about.

~~~
mlthoughts2018
I think they are saying on each probe, a random nameserver and then random
site are chosen. So overall it’s randomizing over all nameservers and sites,
to make the median a more useful metric of the overall TLD.

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.

------
Tepix
I recommend that all DNS servers be in-bailiwick servers with glue.

This recommendation is taken from Dan Bernstein, see
[https://cr.yp.to/djbdns/notes.html](https://cr.yp.to/djbdns/notes.html),
section "Gluelessness"

It not only improves reliability but can help reduce the number of queries and
speed things up.

------
vegardx
I mean, that would probably be true if DNS wasn't distributed and highly
cacheable. But seeing that it is I would be surprised if you'd see anything
other than statistical anomalies on a domain with even a limited traffic and
poorly configured TTLs.

------
siscia
A little off topic, but some of you folks have experience with bunnycdn, the
company behind the post?

Are they fine?

~~~
jlelse
Yeah, they are doing an amazing job.

~~~
siscia
Thanks!

------
davidgf
Interestingly enough, the .top domain gives what it promises: it's at the top
of the worst performing TLDs list

------
neurostimulant
> The biggest shockers were the .info and .org domains that showed really poor
> performance especially in the 85 percentile range, despite being one of the
> oldest and well established top-level domains with millions of registered
> domains each. After some further investigation it appears 4 out of 6 of
> their nameservers are performing extremely poorly which is the reason for
> the poor results.

I always thought with all the money collected from ten million .org domains
they would have an army of nameservers to make sure latency is low, instead
they actually only have 6 nameservers and are performing poorly? Sure it'll
probably won't impact real world performance but I'm still disappointed that
they seem to be only doing bare minimum. I wonder where those hundred million
bucks actually goes?

~~~
Ayesh
Most TLDs run the bare minimum amount of nameservers required by ICANN,
specially the newer TLDs. However, hundreds of nameservers scattered around
the globe wouldn't help much either, because they just need to have faster
responses to the mass of recursive resolvers.

~~~
toast0
Hundreds of nameservers scattered around the globe with anycast absolutely
helps.

The main thing between a DNS request and a DNS response is network round trip
time. Actually processing the request should be trivial (especially for .org,
but even at .com), the zone file may be large compared to most, but it's all
static records, with batched updates. I remember when internic would do
updates at midnight, but you might not make it in the batch; mostly I see 5-20
minute delays on changes now.

------
d2wa
Independently reproduced the tests for .com and .blog. Found that many of the
TLDs at the bottom of BunnyCDN’s list has one thing in common: CentralNic.
Avoid using any TLD that use it for their backend infrastructure.
[https://www.ctrl.blog/entry/dotblog-tld-
performance.html](https://www.ctrl.blog/entry/dotblog-tld-performance.html)

------
sandGorgon
Damn the India cctld is the second fastest cctld out there - almost at par
with .us . Not sure where the tests were ran - probably in EU/US, so this is
actually really good.

It pretty much outperforms .com/.net/.org

#MakeInIndia

~~~
anaganisk
How is make in india even relevant to resolution/cache?

------
Aissen
That's something for which we might want to see the raw data: to sort by
region, see other percentiles, analyze whether it's bunnycdn's connectivity ?

Also, it might be nice to be able to re-do the tests; better yet: have a
website that's auto-updated so that we see results today (maybe TLD X had an
incident when they were measuring?). Of course, that's not something you can
ask a random stranger on the internet to do for you.

------
ShorsHammer
> The biggest shockers were the .info and .org domains that showed really poor
> performance especially in the 85 percentile range, despite being one of the
> oldest and well established top-level domains with millions of registered
> domains each

Why do I imagine this being spun into some upbeat marketing exercise for .org?

------
st_goliath
Friendly reminder for people on HN reading this:

I know this is actually quite interesting, but before you start worrying about
the latency of the name servers of your TLD, you might want to do something
about the metric ton of JavaScript on your site and the 25 different 3rd party
servers from which you side load most of it. Also those 6 additional servers
from which you load a bunch of TTF fonts. Especially if all your site does is
just display some text and two or three pictures.

~~~
RL_Quine
No kidding. I'm using a > 1GBit fibre line and the majority of my page loads
is still downloading recursive, pointless javascript dependencies, or doing a
billion CORS OPTIONS requests and waiting for the response. DNS latency
doesn't even factor into the end result user experience, it's dominated
entirely by front end design decisions.

If this was a concern it’s an admission that JavaScript developers have
optimized to the best of their ability. Which is just sad.

~~~
tgv
Do you have a moment to talk about The Great Saver, uMatrix?

~~~
RL_Quine
Disabling a lot of the bloat makes random pages break, which is an even worse
experience.

~~~
jerf
But it is compensated for by the sites that actually _work better_ when you
strip their non-local JS from them. I've lost track of the number of times
I've come to the HN comments and read about how unreadable the page was due to
all the popups and ads and modal dialogs when I just read the text. You're
absolutely not wrong that some sites get worse, but it's not one-sided in that
direction.

~~~
swinglock
uBlock Origin is probably the better middle way for most. It should accomplish
what you describe most of the time yet breakage is the exception instead of
the rule.

------
arkitaip
ccTLDs like .ru kinda make sense being slower on a global scale because they
mainly target a national audience, but a lot of the worst offenders are gTLDs
where your audience can be anywhere on the planet.

------
3xblah
I once read that the person running the .co registry was a k user and released
his own k-like language. I wonder if that has anything to do with the speed of
the .co TLD

------
cordite
Was this tested with different geographic points to account for latency across
the earth?

------
sdan
I find this a bit hard to believe. Who's servers were you running this test
on? Which regions exactly?

Is there any other sources that back up this claim?

Also interesting that .in (even though indian tld) is faster...

~~~
Tade0
The company I used to work for switched from .io to .dev, because the former
had issues with availability.

------
dreamcompiler
Off topic: My first thought was "Andrew Huang has a CDN?" but then remembered
he spells his nickname differently. Never mind.

------
mxuribe
Well, this is disappointing. As others have stated , clearly there usually are
other areas (easier targets like too much javascript or tracker code crap) to
optimize performance than here. But what i find disappointing is that i was
under the belief that things like a TLD were merely cosmetic and didn't have
an impact on underlying performance. Domain names were supposed to be sticky
labels on more important underlying infrastructure. I always thought that
choosing a .COM, .NET, .WHATEVER didn't matter for delivering digital assets
across the internets to one's customers/users...well, if bunnycdn is onto
something, color me surprised, and slightly saddened.

I've owned my own {$last_name}.CC domain name, and have used it as the basis
for my personal/family email for over a decade, and am quite aware of how it
has gotten treated at least on the spam front. Admittedly, I've had very, very
minor issues compared to many others who have used other seemingly "non-
traditional" TLDs/ccTLDs. (I attribute the low issues to having used G Suite
for many years. Spam fighting: One of the few good things i like about
google.) While the .CC tld was originally based on a country code, it was
marketed (and i guessed managed) for many years now as a generic TLD. My
friend gave me the idea to use it after he set his domain name up for his
then-nascent (ahem) _computer consultancy_ ...And, since the .COM, and the
.NET versions[0] of my $last_name at the time were not available for me, i
went with a nice short and sweet .CC domain. Back then i also felt a mild
sense of edginess for using something different than "boring old" .COM, or
.NET. But i never figured there would be DNS/nme resolution performance
issues...Its just a name resolve process going from some arbitrary text name
to ip addresses, etc...why should there be an issue, right?

Beyond the admittedly minor spam issues that I've had with using a "non-
traditional" TLD, the biggest headache by far is having to educate people that
the world has more than just .COM and .NET domain names. Having to emphasize
(both verbally spell out, and through bold text or caps while written) that my
email address ends in .CC and _NOT_ .COM is quite annoying. After so many
years, it still has not lessened much...At least not in the U.S. - where i
live and work. However, strangely/unexpectedly, outside the U.S. this issue is
vastly less of a thing. During the last 2 years I've traveled to many parts of
the world for my dayjob, and wow, my {$last_name}.CC domain name is pretty
much not an issue outside of the U.S. So this whole time it's my own Americans
who lack the literacy in this regard. From my experience, in the minds of
typical, layperson Americans there exists only .COM, .NET, .ORG, maybe
sometimes .UK...But everything else might as well be .SPAM or .FAKE ;-)

So, after the spam, after all the years of annoyance of emphasizing the
spelling of the TLD, and now there could be possible performance issues!?!
Man, this whole domain name thing sucks (to say nothing even of the sleazy
business/marketing side of the racket). I mean, weren't domain names supposed
to make things easier than having to remember arbitrary IP numbers/addresses?
I think we need a new method or system.

[0] By the way, the .ORG version for my domain name was available years ago,
but I wasn't a non-profit, so felt i didn't want to grab it; happily allowing
any true, legitimate non-profit to scoop it up. My mental jury is still out on
whether that was a wise decision that i made or not. Because of recent news of
the .ORG registry, maybe I'll make a separate post on this topic.

~~~
toast0
> 0] By the way, the .ORG version for my domain name was available years ago,
> but I wasn't a non-profit, so felt i didn't want to grab it; happily
> allowing any true, legitimate non-profit to scoop it up. My mental jury is
> still out on whether that was a wise decision that i made or not. Because of
> recent news of the .ORG registry, maybe I'll make a separate post on this
> topic.

Not that it matters, but in my mind, .COM stood for commercial businesses,
.NET stood for networks/isps, and .ORG stood for the rest. Do you have any
real relation to the Cocos islands? That's less acceptable to me than putting
yourself in .ORG.

~~~
mxuribe
I share your perception of what .COM, .NET, and .ORG stood for. And, to answer
your question, i have no relation to the Cocos islands...further, if I were
somehow negatively impacting the inhabitants of said region, i would have
never obtained the domain name. (I'm not that kind of person.) Besides, the
domain name was for my personal/family email only, that's it - not any
commercial entity or network service, etc. - there was no .FAMILY (or similar
tld) back then.

Nevertheless, to clarify why i had obtained a domain name using that
tld...While yes, .CC was originally (and for a very short period) _intended_
for the Cocos islands, it quickly shifted focus (by those same owners of the
NIC/registry that controlled the TLD) and was promoted for international
registration; in fact the marketing i saw pushed it as the next .COM for
computer hobbyists, etc. And, I wasn't the only one who bought that line; see
[https://en.wikipedia.org/wiki/.cc#Usage](https://en.wikipedia.org/wiki/.cc#Usage)

EDIT: Typo corrections.

~~~
toast0
Sorry, I'm aware everyone was/is doing it, and it's encouraged and acceptable.
I see that's not clear from my message; I didn't mean to imply you made a bad
choice.

I just would have ignored the intent of .org or .net before a country tld.

~~~
mxuribe
I appreciate that clarification; all good, no worries. And, yes, having
learned from my .CC experience all these years now, going forward I will
ignore the intents of .org, .net, etc. before looking at ccTLD. Cheers!

