Benchmarking DNS response times of TLDs • Hacker News Board

Re: Benchmarking DNS response times of TLDs

#101

Post by Ayesh » Fri, Jan 10, 2020, 4:11 PM UTC

arthurcolle wrote: post #91

arminiusreturns wrote: post #80

Earlier quoted context omitted.

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 adb…

> rel=dns-prefetch This is amazing! How could I have missed this? How are the loading times affected when using this option, if you care to share?

It largerly depends on how you use it. For example, if you are using standard Google Fonts, you can pre-connect to the fonts file's hostname so the browser already has DNS resolved when the CSS file refers to the font files.

Re: Benchmarking DNS response times of TLDs

#102

Post by kingkool68 » Fri, Jan 10, 2020, 4:12 PM UTC

siscia wrote: post #17

A little off topic, but some of you folks have experience with bunnycdn, the company behind the post? Are they fine?

I've been using them for several years. Saved our local news startup a boatload compared to CloudFront. What we pay in a year for BunnyCDN would equal one month on CloudFront.

Re: Benchmarking DNS response times of TLDs

#103

Post by cordite » Fri, Jan 10, 2020, 4:13 PM UTC

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

Re: Benchmarking DNS response times of TLDs

#104

Post by Ayesh » Fri, Jan 10, 2020, 4:18 PM UTC

neurostimulant wrote: post #95

> 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 t…

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.

Re: Benchmarking DNS response times of TLDs

#105

Post by swinglock » Fri, Jan 10, 2020, 4:22 PM UTC

jerf wrote: post #81

RL_Quine wrote: post #69

Earlier quoted context omitted.

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

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.

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.

Re: Benchmarking DNS response times of TLDs

#106

Post by JdeBP » Fri, Jan 10, 2020, 4:27 PM UTC

dfawcus wrote: post #68

Eikon wrote: post #21

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

So maybe we should define a DNS SRV record ( https://tools.ietf.org/html/rfc2782 ) for WWW, and work to get the browsers using it? e.g. _http._tcp.example.com and _https._tcp.example.com It seems there was such a draft: https://tools.ietf.org/html/draft-andrews-http-srv-02

Enjoy http://jdebp.uk./FGA/dns-srv-record-use-by-clients.html#HTTP and http://jdebp.uk./FGA/dns-srv-record-use-by-clients.html#Sham... .

Re: Benchmarking DNS response times of TLDs

#107

Post by toast0 » Fri, Jan 10, 2020, 4:50 PM UTC

gregmac wrote: post #70

867-5309 wrote: post #50

Earlier quoted context omitted.

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'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:// traffic (also doing a 301 redirect).

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

I'm opinionated enough to say if you type http://example.org/foo, I'm just going to redirect that to 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)

Re: Benchmarking DNS response times of TLDs

#108

Post by toast0 » Fri, Jan 10, 2020, 4:58 PM UTC

XelNika wrote: post #53

Eikon wrote: post #44

Earlier quoted context omitted.

> What's so "nasty" about using ALIAS? It's a not standard and therefore, is not a generally applicable solution. When something not standard becomes common practice and is expected, here comes the pain.

I don't really see the issue. It changes nothing from the DNS client's perspective.

From the DNS client's perspective, there is a positive and a negative.

Positive: since the server with an alias record actually returns an A/AAAA, a client doesn't have to contact any more servers to get the results.

Negative: the servers for the CNAME target may be faster, relevant if the name is used beyond the A/AAAA TTL but sooner than the TTL would be set for a CNAME); or the servers for the target may be providing much finer targeting than is possibly by proxying.

Re: Benchmarking DNS response times of TLDs

#109

Post by dylz » Fri, Jan 10, 2020, 5:12 PM UTC

sdan wrote: post #10

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

.in is technically-operated by Neustar.

Re: Benchmarking DNS response times of TLDs

#110

Post by toast0 » Fri, Jan 10, 2020, 5:13 PM UTC

Ayesh wrote: post #104

neurostimulant wrote: post #95

> 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 t…

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.

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.