Live data from Hacker News

Benchmarking DNS response times of TLDs

bunnycdn.com

51–60 of 141 posts

Re: Benchmarking DNS response times of TLDs

#51
post #36
post #31

Earlier quoted context omitted.

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

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…

ALIAS is not a valid record.

Re: Benchmarking DNS response times of TLDs

#52
post #42
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.

Re: "... only true for cookies that are not set as 'HostOnly'"

Technically, you're right -- but that implies a commitment to vigilance in setting that attribute on every instance of every cookie across every page or endpoint on your apex domain. Further, if you ever want to support some use of a subdomain, you have to deal with the ability of any page therein to set cookies on ".example.com". And when you inevitably miss any instance of any of these, you're unlikely to notice, because everything will still function normally. So in practice, using the apex paints you into a corner and makes the domain less useful.

There's also the issue of DDOS attacks and related problems, for which the fastest and simplest mitigation is updating DNS entries for your CNAME(s). Why take that option off the table?

Re: Benchmarking DNS response times of TLDs

#53
post #44
post #42

Earlier quoted context omitted.

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

Re: Benchmarking DNS response times of TLDs

#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 your site does is just display some text and two or three pictures.

Re: Benchmarking DNS response times of TLDs

#55
post #44
post #42

Earlier quoted context omitted.

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

> When something not standard becomes common practice and is expected, here comes the pain.

I think that's the case with most popular features before they become a standard. Personally, I've used ALIAS on AWS without a hitch for years.

Re: Benchmarking DNS response times of TLDs

#56
post #31
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.

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

There is lots on the DNS already. For the security argument: Consider you run on `example.com` and at a later stage add `[blog|forum|support|...].example.com` suddenly cookies from `example.com` might leak to those Subdomains. If you put cookies on `www.example.com` they won't leak to those.

Re: Benchmarking DNS response times of TLDs

#57
post #44
post #42

Earlier quoted context omitted.

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

The standard should be amended for the modern web then. AWS's (and I'm sure many other's) implementation of this for their various load balancing, CDN services, etc. are critical to the health of the web now.

Re: Benchmarking DNS response times of TLDs

#59

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 to the best of their ability. Which is just sad.

Re: Benchmarking DNS response times of TLDs

#60
post #17

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

I'm watching them for years. They are from Eastern Europe and started really small (they are not so small nowadays) but they deliver extended (!) features which many other CDNs don't have or like in a 5-10x more expensive premium price range. Also their policy is really relaxed.

Awesome value for the money. You get much more for lower pricing.

Post reply on HN