Live data from Hacker News

Benchmarking DNS response times of TLDs

bunnycdn.com

71–80 of 141 posts

Re: Benchmarking DNS response times of TLDs

#71

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…

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…

Nothing wrong with preflight checks. What’s wrong is that a SPA will make 100 calls to a web server for data that isn’t even that complex.

So much poor API design out there that most would be better off with server side rendering.

Re: Benchmarking DNS response times of TLDs

#73

Earlier quoted context omitted.

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…

Nothing wrong with preflight checks. What’s wrong is that a SPA will make 100 calls to a web server for data that isn’t even that complex. So much poor API design out there that most would be better off with server side rendering.

> So much poor API design out there that most would be better off

...fixing the API design.

Re: Benchmarking DNS response times of TLDs

#74
post #36

Earlier quoted context omitted.

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…

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…

It depends on your audience, but setting it up just so you don't cringe could well be alienating a bunch of your potential user base. Seems like a strange trade-off.

I think people here often forget that there's a mass of people out there who are nowhere near as technically literate and wouldn't have the faintest idea of what "DNS" stands for.

Re: Benchmarking DNS response times of TLDs

#75

Earlier quoted context omitted.

Nothing wrong with preflight checks. What’s wrong is that a SPA will make 100 calls to a web server for data that isn’t even that complex. So much poor API design out there that most would be better off with server side rendering.

> So much poor API design out there that most would be better off ...fixing the API design.

Many inexperienced developers don't understand the difference in latency between a local memory call and a remote HTTP API call, so treat the two as equal in terms of architectural concerns.

Re: Benchmarking DNS response times of TLDs

#76
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.

Re: Benchmarking DNS response times of TLDs

#77
post #66

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'm interested in the NHS systems which didn't recognise the newer TLDs. I work for NHSX - could you drop me an email with the details? My contact details are in my profile. Thanks!

Sure - I'll drop them an email to see if they can remember. They changed towards the middle of last year, and it was reported to them by NHS staff rather than them experiencing it first-hand, so their memories may be a bit hazy.

Re: Benchmarking DNS response times of TLDs

#78
post #35

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

Reminds me of .info a decade ago. Guaranteed spam, malware, or phishing.

Re: Benchmarking DNS response times of TLDs

#79
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.

Re: Benchmarking DNS response times of TLDs

#80

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…

To add to this, one thing people tend to forget is that html has a dns prefetch option for offsite js you absolutely must have. (rel=dns-prefetch)

Of course I agree with goliath, which is why I try very hard to write pure html5+css3 with no JS unless absolutely necessary. It is very rarely necessary. When it is, very rarely do I need one of the crazy frameworks, pure js works pretty well.

Beyond that, this is why adblocker plus and umatrix are two must have addons to firefox. Once you build your asset rule list up with only the couple of js needed to run a site, the same site that takes forever for the average visitor can actually be fairly speedy when none of it's js loads.

Now, for original topic, if you are on windows check out GRC's DNS Benchmark, and if on nix, check out namebench.

Post reply on HN