Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benchmarking DNS response times of TLDs

bunnycdn.com

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Benchmarking DNS response times of TLDs

#111

Post by toast0 »

mxuribe wrote: post #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 underlyi…

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

Re: Benchmarking DNS response times of TLDs

#112

Post by toast0 »

bscphil wrote: post #4

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

This methodology doesn't really consider what recursive resolvers tend to do either.

Recursive resolvers will keep track of performance of the authoritative servers they use and send more queries towards the servers where they get faster responses.

For popular TLDs like .COM/.ORG, it's almost guaranteed your recursive resolver will have enough data to pick a fast authoritative. If you're using a .bike domain though, I'd guess it makes some difference.

Re: Benchmarking DNS response times of TLDs

#113

Post by teddyh »

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

SRV support seems to have been (unfairly, I think) rejected by HTTP vendors and standard bodies. There is a new standard, however, in the works:

https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc...

This one might have a larger chance of being accepted, since it provides some things which HTTP standard bodies and HTTP client vendors want. It doesn’t (at this stage, anyway) provide for the load-balancing “weight” field from the SRV record, but it does support MX-style priority numbers, and also port numbers. Very interesting, to say the least.

Re: Benchmarking DNS response times of TLDs

#114

Post by takeda »

mr__y wrote: post #40
frereubu wrote: post #16

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…

>some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare 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.

I know there was someone in charge of ccTLD, and used just that TLD for personal e-mail (i.e. no dots). That would throw off a lot of validators, but I suppose it also was good to avoid all kinds of robots that were scanning webpages for emails.

Re: Benchmarking DNS response times of TLDs

#115

Post by takeda »

danpalmer wrote: post #8
random_savv wrote: post #6

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.

Seeing so much spam from it, I'm not surprised. I'm thinking to start doing the same.

I am wondering why spammers decided to use it, I'm suspecting it's very trivial to get a domain there.

Re: Benchmarking DNS response times of TLDs

#116

Post by cuspycode »

mr__y wrote: post #40
frereubu wrote: post #16

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…

>some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare 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.

I've had e.g. foo@mysub.mydomain.com rejected by one of the world's top-3 shipping/courier services. This was on a .com domain registered many years ago, so it wasn't a TLD issue. And the subdomain and its MX was also established long ago. But their software finally did accept the mail address after I removed the "mysub." part. Crazy!

Re: Benchmarking DNS response times of TLDs

#117

Post by mxuribe »

toast0 wrote: post #111
mxuribe wrote: post #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 underlyi…

> 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, .CO…

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

EDIT: Typo corrections.

Re: Benchmarking DNS response times of TLDs

#118

Post by pmlnr »

RL_Quine wrote: post #59
st_goliath wrote: post #54

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…

> a billion CORS OPTIONS requests

When I first saw the CORS headers on large sites that are sent with every effin request, I thought I gone mad, only to learn that it's encouraged to be used... I remember times with monsteriusly sized cookies, this is the same, except this won't go away with the rise of server side sessions.

Re: Benchmarking DNS response times of TLDs

#119

Post by rhizome »

RL_Quine wrote: post #59
st_goliath wrote: post #54

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…

It's been a truism for many years now: "slow" is often not your side of the pipe, especially with high-bandwidth connections.

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

I mean sure, but "is this the best you can do?" requires you to know what the goals are, and I suspect the issues raised in these comments are not on hardly any of the lists. New Relic and its third-party cool-usage-graphing friends are way way higher in priority.

Re: Benchmarking DNS response times of TLDs

#120

Post by arminiusreturns »

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 helps more when the offsites are in another geographic location, like if for some reason you are loading something from the EU on a server in the US. Benefits can be marginal otherwise, so I just suggest people play around with it for any offsite requests they have.
Post reply on HN