8 ms·

Saved 10 billion DNS queries per month by disabling DNS Prefetching

159 points by necro 16y ago

Rantenki 16y ago
This implies that providers are either severely limiting their caches, or expiring in a shorter than posted TTL. Even though pinkbike looks like it has thousands of users, one would expect the front pages to be largely identical for most user sessions, so the ISP dns caches should already have most of those username.domain.com records cached. Either that or the ISP's DNS servers are more numerous and distributed, with fewer customers each, or something like that. Anybody at an ISP that can fill us in on DNS TTL mangling or cache limiting?
- ars 16y ago
  See my reply here: http://news.ycombinator.com/item?id=2306788 http://news.ycombinator.com/item?id=2306788 He is creating thousands of unique subdomains, so nobody can cache anything.
  - drwxrwxrwt 16y ago
    username subdomains are a very popular feature with many websites, especially older ones. users like it too. there is nothing abusive about it. He cant scrap several years worth of links and throw everyone at www.example.com/username
    - ars 16y ago
      And? Someone asked why the DNS wasn't caching and I explained.
  - andrewcooke 16y ago
    Why can't this be handled with DNS wildcards? Surely they would allow caching on the nearest server.
- metageek 16y ago
  When I worked on Akamai's DNS server, I was told that most ISPs cached much more aggressively than we told them to. We would set TTLs at...I want to say 5 seconds...because we were directing traffic based on real-time network conditions; but most ISPs would cache for at least an hour. Exact numbers may be off, of course; it was a few years ago.
coderdude 16y ago
I'm surprised the article doesn't actually tell you the meta http-equiv to disable DNS prefetching. It mentions that it helped out tremendously, though. Here it is: <meta http-equiv="x-dns-prefetch-control" content="off" /> or, if you're more into HTML5: <meta http-equiv="x-dns-prefetch-control" content="off">
- buro9 16y ago
  I prefer HTTP headers instead of meta tags where possible. An example solution at the load balancer level, assuming the use of Varnish: In vcl_fetch: if (req.url ~ "\.(htm|html|php)" || req.url ~ "\/(\?.*)?$") { set beresp.http.disable-dns-prefetch = "1"; } In vcl_deliver: if (resp.http.disable-dns-prefetch) { remove resp.http.disable-dns-prefetch; set resp.http.X-DNS-Prefetch-Control = "off"; }
  - blantonl 16y ago
    do all the browsers that support the meta tag support consuming http headers for this "switch"?
    - metageek 16y ago
      Http-equiv is just a way of specifying an HTTP header in your HTML, so they really should.
- rodion_89 16y ago
  Not closing the tag is nothing specific to HTML5, it just means you aren't strict on XHTML. HTML4 and others would be the same.
  - coderdude 16y ago
    Well sure, but why does that matter? I could have said "or if you're more into HTML 4.01, 5, and anything before those versions of HTML..." Pedantic.
togasystems 16y ago
As a fellow Mountain biker, I was surprised and glad that I saw pinkbike on HN.
davidu 16y ago
The real issue is that the cost per query is negligible here and DNS providers shouldn't charge by the query yet almost all of them do. They have to have some metric to separate the big guys from the little guys and charge the big guys more, but this is a crude way to do it. Consider that publishers often have little control of how many DNS requests they get, so to charge for something out of your control seems utterly bizarre to me. Nice to see in this instance, publisher was able to make a meaningful improvement. Also keep in mind, I used to run the largest free DNS service in the world so I'm well aware of what I'm talking about and am totally biased on these matters. :-)
- necro 16y ago
  The thing to note is that implementation of browser prefetching is further putting DNS requests out of the control of the publishers. 10 billion queries was something like 5000 dns req/s and that is considerable resources of some dns service. I wish dns was not per query costs, but it would seem that is the metric that resources would be based on. The point of the article is to let people know that if you fall into this dns pattern, it maybe a result of the recent prefetching done by browsers, and you may have a way to resolve the issue.
  - davidu 16y ago
    Yep -- nice to see that in this instance, as I noted. Then again, why should you be punished for your success if the reasons for query increase are based on simple traffic growth? Or worse, a competitor just sending you a ton of DNS traffic.
  - chrisbolt 16y ago
    Is 5000 dns req/s really a considerable amount of resources? We were previously serving it on old hardware, with negligible (<5%) CPU usage (tinydns) and bandwidth.
    - mryan 16y ago
      If they have a large number of customers all doing 5000 req/s, perhaps they will need something a bit more powerful.
ars 16y ago
Summary (he really should have said this part upfront): He is (ab)using subdomains, by giving every user a different subdomain on his site. So a typical page can have links to hundreds of different subdomains on the page. For a normal site disabling prefetching is not necessary or a good idea. This article should be renamed: "Why using hundreds of unique subdomains is not a good idea." Besides all the DNS queries, you are also messing with caches. I don't know anything about his site, but I don't see any reason that every user needs a unique subdomain.
- bodyfour 16y ago
  One reason to do per-user domains is to prevent cookie leakage caused by user-specified content. A few years ago LiveJournal got bitten by a firefox bug that allowed JS execution inside CSS. Since they allowed each user to style their own page that meant that a malicious user could make the CSS at "www.livejournal.com/~evil_user" capture the viewer's www.livejournal.com cookies. That's why they moved everybody to username.livejournal.com, which previously had been a pay-only feature. I think the really perplexing about this article is why browsers are so aggressive with DNS prefetching. If there are links on the page to 300 different domains, is there much benefit to precaching ALL of them? It seems clear that very few of the domains are likely to be clicked on. If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests. It sounds like browsers need a better precaching heuristic.
  - there 16y ago
    the livejournal change: http://www.davidpashley.com/blog/computing/livejournal-mozilla-bug.html http://www.davidpashley.com/blog/computing/livejournal-mozil...
  - T-hawk 16y ago
    > is there much benefit to precaching ALL of them? ... If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests. It's a tragedy of the commons. Each individual user gains personal performance from DNS prefetching. The gain for each individual user is greater than their loss to their share of the performance penalty imposed on the entire system. The real super smart answer would be predictive prefetching based on pointer movement. When the browser sees the mouse heading towards a link, start prefetching. Or at least on mouseover.
Xk 16y ago
That's all very nice, but it seems to do more with the fact that each person gets his/her own subdomain. And given that I found three xss's in about five minutes [edit: and then like ten more in the next five seconds, after realizing any input box works] doesn't give me confidence in their abilities. http://www.pinkbike.com/news/search/?q=%3C%2Ftitle%3E%3Cscript%3Ealert%28%22xss%22%29%3C%2Fscript%3E&x=0&y=0 http://www.pinkbike.com/news/search/?q=%3C%2Ftitle%3E%3Cscri... http://www.pinkbike.com/product/compare/?items=466,%22%3E%3Cscript%3Ealert%28%22xss%22%29%3C/script%3E http://www.pinkbike.com/product/compare/?items=466,%22%3E%3C... http://www.pinkbike.com/photo/list/?date=all&text=%3C/title%3E%3Cscript%3Ealert%28%22xss%22%29%3C/script%3E http://www.pinkbike.com/photo/list/?date=all&text=%3C/ti... http://www.pinkbike.com/buysell/list/?q=%3Cscript%3Ealert%28%22xss%22%29%3C%2Fscript%3E&category=0&pmin=&pmax=&region=3 http://www.pinkbike.com/buysell/list/?q=%3Cscript%3Ealert%28... http://www.pinkbike.com/forum/search/?q=%3C/title%3E%3Cscript%3Ealert%28%22xss%22%29%3B%3C%2Fscript%3E http://www.pinkbike.com/forum/search/?q=%3C/title%3E%3Cscrip... Edit: I've stopped adding xss's. It's actually harder to find input boxes which don't lead to xss's than ones which do.
- Xk 16y ago
  Whoever it was that fixed the XSS (necro?), I'm impressed how fast that was. But please don't rely on just escaping < and >. You have to worry about double-quotes too, I can end a string and add a "onload" or "onfocus" attribute if it's already in a tag. And sometimes you have to worry about single quotes. In fact, there's a lot to take a look at. Instead of just fixing the case at hand, try to be proactive about it. Check to make sure you don't have anything else. Edit: Click the search box, for example. http://www.pinkbike.com/forum/search/?q=%22%20onclick=%22alert%28%27xss%27%29%22%20foo=%22 http://www.pinkbike.com/forum/search/?q=%22%20onclick=%22ale...
  - necro 16y ago
    Yup. I actually wrote a filter to our framework when it was built years ago, but as new people help out on dev they don't always use the framework. My bad and I do appreciate the smack. I humbly bow to you with egg on my face.
gcb 16y ago
+ saved 10 billion DNS queries per month. - wasted a total of 10sec of each user's time per month. it's all about trade offs
- Rantenki 16y ago
  No, it's not; the issue is that the domains prefetch REGARDLESS of whether the links are ever clicked on. The browser is pre-fetching in case the user DOES click on the link. This really verges on being a browser bug, esp. since in firefox's case, it fetches both A and AAAA records.
  - otterley 16y ago
    The benefit is reaped in the event a link is actually clicked on. That's why browsers do it.
- blantonl 16y ago
  you have neglected to take into consideration the cost of running a hosted DNS. Costs for DNS service for any large traffic site is an important consideration.
  - gcb 16y ago
    Still continue to be about trade offs.... We could waste all day expanding my shallow example with items to weight in. but then we'd had to send a consulting invoice
- chrisbolt 16y ago
  In our (deviantART's) case, the 24-60 links to subdomains were set up so if you clicked them, they dynamically load with javascript on the client side, never actually hitting that subdomain. No time wasted on the user's side, since the browser was prefetching domains that were rarely being hit.
joshfraser 16y ago
Before everyone goes rushing off to disable DNS prefetching, remember that DNS prefetching is generally a good thing that exists to make websites faster. And the faster your site is the more pageviews you can expect. Faster sites also have a lower bounce rate and better pagerank from Google.
- ssp 16y ago
  Does Google take DNS prefetching into account when they measure the speed of a web site?
  - joshfraser 16y ago
    They get their timing data from the Google Toolbar, so yes.
ck2 16y ago
short answer for Firefox about:config network.dns.disablePrefetch (true) network.dns.disablePrefetchFromHTTPS (true)
- hartror 16y ago
  But that is a good thing for me!
- ck2 16y ago
  For those downvoting, did you want the server-side solution? <meta http-equiv="x-dns-prefetch-control" content="off" />
patrickgzill 16y ago
I am actually rather shocked that people are being charged extra for DNS - surely the answer is to get any sort of cheap VPS and put DNS on that box? Then again, why are you depending for all aspects of your site's working at all, on a service which costs $2/month? Even a 128MB RAM VPS could comfortably handle a huge number of requests.
- arbitrarywords 16y ago
  Depends on the location of your users. Quicker to have someone host it is multiple places all over the world (assuming you care about perceived page load speed)
andrewcooke 16y ago
ok i'm confused. why doesn't dns wildcard caching solve this?
- chrisbolt 16y ago
  DNS wildcards are server-side, so there's no way for the client to know that the response they got is for *.domain.com but not www.domain.com.
  - andrewcooke 16y ago
    (I am not an expert on this, so may be wrong, but...) How does that change anything? If the client needs to know foo.example.com they ask the nearest server. That will have the wildcard and will return the correct address. The nearest server is not going to be the root server for that domain, but something (typically) at the ISP. So the ISP DNS server will see more load, but not the root. Yet this article show the root as getting a huge number of hits. The only explanation I see is that they are not serving wildcard responses when they should be...
datums 16y ago
Create an A Record for your highest queried subdomain. Those will be cached and eventually decrease the number of queries. Depending on the number of subdomain you can create and remove it on signup and cancellation.

159 points by necro 16y ago

This implies that providers are either severely limiting their caches, or expiring in a shorter than posted TTL. Even though pinkbike looks like it has thousands of users, one would expect the front pages to be largely identical for most user sessions, so the ISP dns caches should already have most of those username.domain.com records cached. Either that or the ISP's DNS servers are more numerous and distributed, with fewer customers each, or something like that. Anybody at an ISP that can fill us in on DNS TTL mangling or cache limiting?

ars 16y ago
See my reply here: http://news.ycombinator.com/item?id=2306788 http://news.ycombinator.com/item?id=2306788 He is creating thousands of unique subdomains, so nobody can cache anything.
- drwxrwxrwt 16y ago
  username subdomains are a very popular feature with many websites, especially older ones. users like it too. there is nothing abusive about it. He cant scrap several years worth of links and throw everyone at www.example.com/username
  - ars 16y ago
    And? Someone asked why the DNS wasn't caching and I explained.
- andrewcooke 16y ago
  Why can't this be handled with DNS wildcards? Surely they would allow caching on the nearest server.
metageek 16y ago
When I worked on Akamai's DNS server, I was told that most ISPs cached much more aggressively than we told them to. We would set TTLs at...I want to say 5 seconds...because we were directing traffic based on real-time network conditions; but most ISPs would cache for at least an hour. Exact numbers may be off, of course; it was a few years ago.

coderdude 16y ago

I'm surprised the article doesn't actually tell you the meta http-equiv to disable DNS prefetching. It mentions that it helped out tremendously, though. Here it is: <meta http-equiv="x-dns-prefetch-control" content="off" /> or, if you're more into HTML5: <meta http-equiv="x-dns-prefetch-control" content="off">

buro9 16y ago
I prefer HTTP headers instead of meta tags where possible. An example solution at the load balancer level, assuming the use of Varnish: In vcl_fetch: if (req.url ~ "\.(htm|html|php)" || req.url ~ "\/(\?.*)?$") { set beresp.http.disable-dns-prefetch = "1"; } In vcl_deliver: if (resp.http.disable-dns-prefetch) { remove resp.http.disable-dns-prefetch; set resp.http.X-DNS-Prefetch-Control = "off"; }
- blantonl 16y ago
  do all the browsers that support the meta tag support consuming http headers for this "switch"?
  - metageek 16y ago
    Http-equiv is just a way of specifying an HTTP header in your HTML, so they really should.
rodion_89 16y ago
Not closing the tag is nothing specific to HTML5, it just means you aren't strict on XHTML. HTML4 and others would be the same.
- coderdude 16y ago
  Well sure, but why does that matter? I could have said "or if you're more into HTML 4.01, 5, and anything before those versions of HTML..." Pedantic.

togasystems 16y ago

As a fellow Mountain biker, I was surprised and glad that I saw pinkbike on HN.

davidu 16y ago

The real issue is that the cost per query is negligible here and DNS providers shouldn't charge by the query yet almost all of them do. They have to have some metric to separate the big guys from the little guys and charge the big guys more, but this is a crude way to do it. Consider that publishers often have little control of how many DNS requests they get, so to charge for something out of your control seems utterly bizarre to me. Nice to see in this instance, publisher was able to make a meaningful improvement. Also keep in mind, I used to run the largest free DNS service in the world so I'm well aware of what I'm talking about and am totally biased on these matters. :-)

necro 16y ago
The thing to note is that implementation of browser prefetching is further putting DNS requests out of the control of the publishers. 10 billion queries was something like 5000 dns req/s and that is considerable resources of some dns service. I wish dns was not per query costs, but it would seem that is the metric that resources would be based on. The point of the article is to let people know that if you fall into this dns pattern, it maybe a result of the recent prefetching done by browsers, and you may have a way to resolve the issue.
- davidu 16y ago
  Yep -- nice to see that in this instance, as I noted. Then again, why should you be punished for your success if the reasons for query increase are based on simple traffic growth? Or worse, a competitor just sending you a ton of DNS traffic.
- chrisbolt 16y ago
  Is 5000 dns req/s really a considerable amount of resources? We were previously serving it on old hardware, with negligible (<5%) CPU usage (tinydns) and bandwidth.
  - mryan 16y ago
    If they have a large number of customers all doing 5000 req/s, perhaps they will need something a bit more powerful.

ars 16y ago

Summary (he really should have said this part upfront): He is (ab)using subdomains, by giving every user a different subdomain on his site. So a typical page can have links to hundreds of different subdomains on the page. For a normal site disabling prefetching is not necessary or a good idea. This article should be renamed: "Why using hundreds of unique subdomains is not a good idea." Besides all the DNS queries, you are also messing with caches. I don't know anything about his site, but I don't see any reason that every user needs a unique subdomain.

bodyfour 16y ago
One reason to do per-user domains is to prevent cookie leakage caused by user-specified content. A few years ago LiveJournal got bitten by a firefox bug that allowed JS execution inside CSS. Since they allowed each user to style their own page that meant that a malicious user could make the CSS at "www.livejournal.com/~evil_user" capture the viewer's www.livejournal.com cookies. That's why they moved everybody to username.livejournal.com, which previously had been a pay-only feature. I think the really perplexing about this article is why browsers are so aggressive with DNS prefetching. If there are links on the page to 300 different domains, is there much benefit to precaching ALL of them? It seems clear that very few of the domains are likely to be clicked on. If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests. It sounds like browsers need a better precaching heuristic.
- there 16y ago
  the livejournal change: http://www.davidpashley.com/blog/computing/livejournal-mozilla-bug.html http://www.davidpashley.com/blog/computing/livejournal-mozil...
- T-hawk 16y ago
  > is there much benefit to precaching ALL of them? ... If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests. It's a tragedy of the commons. Each individual user gains personal performance from DNS prefetching. The gain for each individual user is greater than their loss to their share of the performance penalty imposed on the entire system. The real super smart answer would be predictive prefetching based on pointer movement. When the browser sees the mouse heading towards a link, start prefetching. Or at least on mouseover.

Xk 16y ago

That's all very nice, but it seems to do more with the fact that each person gets his/her own subdomain. And given that I found three xss's in about five minutes [edit: and then like ten more in the next five seconds, after realizing any input box works] doesn't give me confidence in their abilities. http://www.pinkbike.com/news/search/?q=%3C%2Ftitle%3E%3Cscript%3Ealert%28%22xss%22%29%3C%2Fscript%3E&x=0&y=0 http://www.pinkbike.com/news/search/?q=%3C%2Ftitle%3E%3Cscri... http://www.pinkbike.com/product/compare/?items=466,%22%3E%3Cscript%3Ealert%28%22xss%22%29%3C/script%3E http://www.pinkbike.com/product/compare/?items=466,%22%3E%3C... http://www.pinkbike.com/photo/list/?date=all&text=%3C/title%3E%3Cscript%3Ealert%28%22xss%22%29%3C/script%3E http://www.pinkbike.com/photo/list/?date=all&text=%3C/ti... http://www.pinkbike.com/buysell/list/?q=%3Cscript%3Ealert%28%22xss%22%29%3C%2Fscript%3E&category=0&pmin=&pmax=&region=3 http://www.pinkbike.com/buysell/list/?q=%3Cscript%3Ealert%28... http://www.pinkbike.com/forum/search/?q=%3C/title%3E%3Cscript%3Ealert%28%22xss%22%29%3B%3C%2Fscript%3E http://www.pinkbike.com/forum/search/?q=%3C/title%3E%3Cscrip... Edit: I've stopped adding xss's. It's actually harder to find input boxes which don't lead to xss's than ones which do.

Xk 16y ago
Whoever it was that fixed the XSS (necro?), I'm impressed how fast that was. But please don't rely on just escaping < and >. You have to worry about double-quotes too, I can end a string and add a "onload" or "onfocus" attribute if it's already in a tag. And sometimes you have to worry about single quotes. In fact, there's a lot to take a look at. Instead of just fixing the case at hand, try to be proactive about it. Check to make sure you don't have anything else. Edit: Click the search box, for example. http://www.pinkbike.com/forum/search/?q=%22%20onclick=%22alert%28%27xss%27%29%22%20foo=%22 http://www.pinkbike.com/forum/search/?q=%22%20onclick=%22ale...
- necro 16y ago
  Yup. I actually wrote a filter to our framework when it was built years ago, but as new people help out on dev they don't always use the framework. My bad and I do appreciate the smack. I humbly bow to you with egg on my face.

gcb 16y ago

+ saved 10 billion DNS queries per month. - wasted a total of 10sec of each user's time per month. it's all about trade offs

Rantenki 16y ago
No, it's not; the issue is that the domains prefetch REGARDLESS of whether the links are ever clicked on. The browser is pre-fetching in case the user DOES click on the link. This really verges on being a browser bug, esp. since in firefox's case, it fetches both A and AAAA records.
- otterley 16y ago
  The benefit is reaped in the event a link is actually clicked on. That's why browsers do it.
blantonl 16y ago
you have neglected to take into consideration the cost of running a hosted DNS. Costs for DNS service for any large traffic site is an important consideration.
- gcb 16y ago
  Still continue to be about trade offs.... We could waste all day expanding my shallow example with items to weight in. but then we'd had to send a consulting invoice
chrisbolt 16y ago
In our (deviantART's) case, the 24-60 links to subdomains were set up so if you clicked them, they dynamically load with javascript on the client side, never actually hitting that subdomain. No time wasted on the user's side, since the browser was prefetching domains that were rarely being hit.

joshfraser 16y ago

Before everyone goes rushing off to disable DNS prefetching, remember that DNS prefetching is generally a good thing that exists to make websites faster. And the faster your site is the more pageviews you can expect. Faster sites also have a lower bounce rate and better pagerank from Google.

ssp 16y ago
Does Google take DNS prefetching into account when they measure the speed of a web site?
- joshfraser 16y ago
  They get their timing data from the Google Toolbar, so yes.

ck2 16y ago

short answer for Firefox about:config network.dns.disablePrefetch (true) network.dns.disablePrefetchFromHTTPS (true)

hartror 16y ago
But that is a good thing for me!
ck2 16y ago
For those downvoting, did you want the server-side solution? <meta http-equiv="x-dns-prefetch-control" content="off" />

patrickgzill 16y ago

I am actually rather shocked that people are being charged extra for DNS - surely the answer is to get any sort of cheap VPS and put DNS on that box? Then again, why are you depending for all aspects of your site's working at all, on a service which costs $2/month? Even a 128MB RAM VPS could comfortably handle a huge number of requests.

arbitrarywords 16y ago
Depends on the location of your users. Quicker to have someone host it is multiple places all over the world (assuming you care about perceived page load speed)

andrewcooke 16y ago

ok i'm confused. why doesn't dns wildcard caching solve this?

chrisbolt 16y ago
DNS wildcards are server-side, so there's no way for the client to know that the response they got is for *.domain.com but not www.domain.com.
- andrewcooke 16y ago
  (I am not an expert on this, so may be wrong, but...) How does that change anything? If the client needs to know foo.example.com they ask the nearest server. That will have the wildcard and will return the correct address. The nearest server is not going to be the root server for that domain, but something (typically) at the ISP. So the ISP DNS server will see more load, but not the root. Yet this article show the root as getting a huge number of hits. The only explanation I see is that they are not serving wildcard responses when they should be...

datums 16y ago

Create an A Record for your highest queried subdomain. Those will be cached and eventually decrease the number of queries. Depending on the number of subdomain you can create and remove it on signup and cancellation.