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. :-)
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.
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.
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.
Perhaps a per-query charge isn't optimal, but how else can a provider of a service equate supply with demand?
More load implies additional cost, and DNS providers are no exception; there is an incremental cost of serving a DNS response. Granted, it's small, but real nonetheless.
One could charge based on bytes transferred instead, but charging for bytes is functionally equivalent to charging for responses.
Comments
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. :-)
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.
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.
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.
If they have a large number of customers all doing 5000 req/s, perhaps they will need something a bit more powerful.
Perhaps a per-query charge isn't optimal, but how else can a provider of a service equate supply with demand?
More load implies additional cost, and DNS providers are no exception; there is an incremental cost of serving a DNS response. Granted, it's small, but real nonetheless.
One could charge based on bytes transferred instead, but charging for bytes is functionally equivalent to charging for responses.