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

61–70 of 141 posts

Re: Benchmarking DNS response times of TLDs

#61

Post by belorn »

cbg0 wrote: post #42
Eikon wrote: 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…

What's so "nasty" about using ALIAS? > 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`. This is only true for cookies that are not set as `HostOnly` as far as I'm aware.

> What's so "nasty" about using ALIAS?

The DNS server provide implements this differently, but the two "common" methods I know of is either aggressive caching or caching on request. In both cases the server becomes the client, breaks geoip, and create complexity where errors can easily slip in.

Re: Benchmarking DNS response times of TLDs

#62

Post by mr__y »

mytailorisrich wrote: post #48
mr__y wrote: post #40

Earlier quoted context omitted.

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

And I've seen validation that assumed that TLDs were 2 or 3 characters only.

Oh yes, a simple [a-z]{2,3} in regexp. I'm pretty sure I've seen exactly this on many different occasions

Re: Benchmarking DNS response times of TLDs

#63

Post by slig »

867-5309 wrote: post #50
Eikon wrote: 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…

Now that Chrome is hiding the "www." it's going to look more and more legacy. I still use the "www." and probably will continue using, but for business cards and things like that I always use the bare domain.

Re: Benchmarking DNS response times of TLDs

#64

Post by anaganisk »

sandGorgon wrote: post #12

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

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

Re: Benchmarking DNS response times of TLDs

#65

Post by social_quotient »

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…

Are you suggesting this might be a premature optimization? :)

Re: Benchmarking DNS response times of TLDs

#66

Post by edent »

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…

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!

Re: Benchmarking DNS response times of TLDs

#67

Post by tgv »

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…

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

Re: Benchmarking DNS response times of TLDs

#68

Post by dfawcus »

Eikon wrote: post #21
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…

> 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

Re: Benchmarking DNS response times of TLDs

#69

Post by RL_Quine »

tgv wrote: post #67
RL_Quine wrote: post #59

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…

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

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

Re: Benchmarking DNS response times of TLDs

#70

Post by gregmac »

867-5309 wrote: post #50
Eikon wrote: 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'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).

Post reply on HN