For such an accusation of public fraud, on any other site folks would ask for at least a URL, any URL, to substantiate your specific claim.
But I suspect no one here will ask for it, and I'm not holding my breath expecting you to be able to come up with one....
Simply the wording of the questions and the simplistic answers points to the fact that the FAQ is not the whole story. The questions appear to be carefully crafted so as to allow the answer, "No," without actually having the "denial" constitute fraud. To any thoughtful person, the careful construction of these questions ought to raise a red flag that Google is not being entirely honest and straightforward.
If Google isn't engaged in these activities and if they want to clear the air, why don't they publish a sworn statement telling us exactly what they are doing, what information they are collecting, how they are using it, and exactly what is being shared with whom, including internal and external "partners"? Better yet, why don't they submit to direct questioning by an outside party like the EFF? Google won't do this because they don't want to reveal the extent of information they collect and the level of detail they maintain in personal profiles.
Sorry, but a self-serving, carefully phrased, sophisticated FAQ of denial doesn't hold a lot of credibility when critically examined.
I don't get is this notion that, because I'm critical/skeptical of Google, I have to somehow defend anything that Apple does. Anyone who knows me knows I've been plenty critical of Apple where they deserve it. But if Google doesn't scare you just a little bit, it's possible that you haven't been paying close enough attention.
Quote:
Originally Posted by MacRulez
Quote:
Originally Posted by John.B
An FAQ can say whatever they want it to say, whatever is expedient, whatever furthers their corporate goals.
For such an accusation of public fraud, on any other site folks would ask for at least a URL, any URL, to substantiate your specific claim.
But I suspect no one here will ask for it, and I'm not holding my breath expecting you to be able to come up with one....
Where did I say that? Show me these supposed "accusations". You are simply putting your own words into my post. What I said was:
Quote:
Originally Posted by John.B
An FAQ can say whatever they want it to say, whatever is expedient, whatever furthers their corporate goals. It's not as if this carries the legal weight of, for example, a sworn deposition by Eric Schmidt.
I said that some FAQ posted to their developer sitecarries no legal weight. No FAQ does. It could say anything and you would have no legal recourse. That's not just applicable to Google, any technology company could have an FAQ full of inaccuracies or that lacked a full disclosure of the facts. An FAQ is not a contract, nor is it a legal document; it infers no rights.
And it's worth pointing out that neither Google's Street View FAQ or their main Privacy FAQ disclosed the active WiFi data collection underway during their "sweeps". So there is a prior history. Integrity is a funny thing; once your reputation is suspect, people tend to question your intentions and motivations about everything you do.
Yes. FFS people just try your Intarwebs with OpenDNS or similar and without it, and judge for yourselves. As for Google, either give your life to it or don't (ChromeOS is disturbing, to me). Thank you for your attention, end of story.
I use my ISP's DNS, which is Oceanic Time Warner in Hawaii.
My ATV2 worked perfectly for all of my movies prior to installing the update. Everything started well within 1 minute on my 11mb connection.
Since the update, Netflix still works perfectly, previews still work perfectly. Only movie rentals have the long download problem. Unable to determine the time one day, 232 minutes the next... had to pause again for an hour 2/3's of the way through.
The problem is the Update, not DNS. Perhaps the update changed something about the way ATV2 uses DNS, but it doesn't change the fact that the root problem lies somewhere within the Update.
By the way, if you read the thread on Apple support, you will see that people with both ATV and ATV2 in the same household only have the problem on ATV2.
And people who take their ATV2 back and exchange it for one with the previous iOS version don't have the problem anymore.
You, sir, are absolutely correct. I find it amazing that I've seen this posted on a lot of "techie" websites, you would think that a WEBSITE would know how DNS works.
The only reason adding Google DNS to your list of servers would speed up web browsing is it helps your computer find all the links to all the Ads posted on the webpages, so your page finishes drawing faster.
As many have already said, this article is misinformed on many levels, and shows that the author doesn't really understand DNS at all.
1. DNS is simply a directory for matching human-readable names (i.e. apple.com, cnn.com, yahoo.com) with an IP address that computers understand. It doesn't have ANYTHING with setting routes (or "paths", as the author states) to/from your computer and the site!
2. the point of third-party DNS services, like Google or OpenDNS, is to speed up your surfing-- these servers are typically dramatically faster-responding than your usual ISP. Switch, and you'll see the difference.
3. Once your computer has connected to a site to download, stream, etc., DNS has no role in that process. A DNS server WILL NOT affect your download speed!
4. it is trivial for a company to block users from setting their own DNS-- simply block port 53 on the firewall (except for your main DNS server, of course). Any user setting their own DNS to anything other than the corporate DNS will be surprised to find they can no longer surf the web.
Although this article doesn't clearly identify what the real inefficiency is caused by this problem, it does exist and due to the way Akamai operates and it can have an effect if you are not using your ISP's name servers.
When you send a query for a web site to your recursive DNS server, usually your ISP's, that server in turn will query the CDN's DNS server(s) after recursing from the root zone down to the appropriate TLD zones and possibly other zones until it lands on the CDN's DNS server. Now that server doesn't know who initiated the query, but it knows the IP address of the recursive DNS server where the query came from. That CDN, Akamai for example, can have a database of IP's mapped to locations. Based on this, they will typically respond with a geographically close cluster of servers to the originating recursive DNS server. It's assumed the client who made the query to the DNS server in the first place is also reasonably close. That's where the problem can come from.
Certain recursive DNS servers also actually give you different results. OpenDNS for instance gives you a different result for google.com than most of the Internet. This is specialized for them. The purpose of that I'm not entirely certain.
Anyway, if the server you are told to connect to ends up being geographically further away, the latency is higher in reaching this server. Due to the way TCP functions (without specialized techniques like negotiated window scaling on both the server and client side), throughput is directly correlated to the latency in reaching that server. TCP is a reliable protocol, so there is an acknowledgement for each packet that is sent. If the latency is higher it takes longer to send the same number of requests and acknowledgements in the TCP stream. You can equate this to transporting boxes in your car between two towns. If you have 100 boxes to transport and can only fit 10 in your car at a time, that's 10 trips. Now if you're going between two towns that are 10 miles apart vs. 20 miles apart, it's obviously going to take you longer to transport all 100 boxes between the towns that are 20 miles apart. Equate the car to a TCP packet, the boxes to data and the miles to latency. If you got a larger vehicle to transport the boxes you could fit more and do it in less time even if the distance is further apart. This is equated to TCP window scaling.
So, all things being equal, your throughput is limited by the inherent nature of TCP and latency. I had a formula for this one time where you could calculate it exactly but I don't have it handy. UDP isn't bound by this restriction as it doesn't do any checks that data has arrived. This is why it is often used in DDOS attacks (besides the fact that it is easily spoofed). You can easily flood a pipe of any size with UDP, but you have to write the software to handle the error correction and retransmission of lost packets.
So in the end, yes it does matter if you use a DNS server other than your ISP's and it can ultimately affect throughput as the CDN will tell you to go to the server it thinks is closest to you. Is this always a limitation? Absolutely not. It depends on how the DNS service is setup. If you're using Google for example, just because you query 8.8.8.8, that doesn't mean that's a single server in a single location in the world. It's likely anycast which means many servers around the world all use that same IP address. You are just routed to the closest one. What this also means is that the queries from that server CANNOT originate from that 8.8.8.8 address to resolve things. Otherwise the responses would go to the nearest server to the authoritative DNS server for the domain being queried and you'd never get a response. All the DNS servers also have unique IP addresses that they source the queries from. It's likely that Google hasn't shared the IP information for their DNS service with the CDN's to optimally provide the best local server. Once that happens, this problem will likely go away, but Google tends to be very secretive with all of their internal network information.
Hope this helps clear things up a little and touches on topics that I believe should have been in the original article for completeness.
Also, for the record I don't use OpenDNS, Google DNS, or my ISP's DNS. I don't trust any of them because of the modifications they do to DNS results. I run my own DNS server in my home that I have complete control over, in addition to providing DNSSEC which I know my ISP's servers do not, and I'm unsure about OpenDNS or Google.
I use my ISP's DNS, which is Oceanic Time Warner in Hawaii.
My ATV2 worked perfectly for all of my movies prior to installing the update. Everything started well within 1 minute on my 11mb connection.
Since the update, Netflix still works perfectly, previews still work perfectly. Only movie rentals have the long download problem. Unable to determine the time one day, 232 minutes the next... had to pause again for an hour 2/3's of the way through.
The problem is the Update, not DNS. Perhaps the update changed something about the way ATV2 uses DNS, but it doesn't change the fact that the root problem lies somewhere within the Update.
By the way, if you read the thread on Apple support, you will see that people with both ATV and ATV2 in the same household only have the problem on ATV2.
And people who take their ATV2 back and exchange it for one with the previous iOS version don't have the problem anymore.
i agree with this, although i'm having issues with all forms of downloads with the 4.2.1 update for ATV2, google dns or otherwise. worked perfectly out of the box, updated and then crippled.
Comments
For such an accusation of public fraud, on any other site folks would ask for at least a URL, any URL, to substantiate your specific claim.
But I suspect no one here will ask for it, and I'm not holding my breath expecting you to be able to come up with one....
Simply the wording of the questions and the simplistic answers points to the fact that the FAQ is not the whole story. The questions appear to be carefully crafted so as to allow the answer, "No," without actually having the "denial" constitute fraud. To any thoughtful person, the careful construction of these questions ought to raise a red flag that Google is not being entirely honest and straightforward.
If Google isn't engaged in these activities and if they want to clear the air, why don't they publish a sworn statement telling us exactly what they are doing, what information they are collecting, how they are using it, and exactly what is being shared with whom, including internal and external "partners"? Better yet, why don't they submit to direct questioning by an outside party like the EFF? Google won't do this because they don't want to reveal the extent of information they collect and the level of detail they maintain in personal profiles.
Sorry, but a self-serving, carefully phrased, sophisticated FAQ of denial doesn't hold a lot of credibility when critically examined.
That means for those whom dont get it:
- Use ISP DNS = works allways.
I first started researching alternate DNS servers because my ISP's DNS servers were so flaky!
Back to post #2 of this thread:
4.2.2.2
4.2.2.1
An FAQ can say whatever they want it to say, whatever is expedient, whatever furthers their corporate goals.
For such an accusation of public fraud, on any other site folks would ask for at least a URL, any URL, to substantiate your specific claim.
But I suspect no one here will ask for it, and I'm not holding my breath expecting you to be able to come up with one....
Where did I say that? Show me these supposed "accusations". You are simply putting your own words into my post. What I said was:
An FAQ can say whatever they want it to say, whatever is expedient, whatever furthers their corporate goals. It's not as if this carries the legal weight of, for example, a sworn deposition by Eric Schmidt.
I said that some FAQ posted to their developer site carries no legal weight. No FAQ does. It could say anything and you would have no legal recourse. That's not just applicable to Google, any technology company could have an FAQ full of inaccuracies or that lacked a full disclosure of the facts. An FAQ is not a contract, nor is it a legal document; it infers no rights.
And it's worth pointing out that neither Google's Street View FAQ or their main Privacy FAQ disclosed the active WiFi data collection underway during their "sweeps". So there is a prior history. Integrity is a funny thing; once your reputation is suspect, people tend to question your intentions and motivations about everything you do.
FWIW, I couldn't find where Google's main privacy FAQ mentioned anything about DNS data collection, one way or another: http://www.google.com/intl/en/privacy/faq.html
deleted
deleted
I use my ISP's DNS, which is Oceanic Time Warner in Hawaii.
My ATV2 worked perfectly for all of my movies prior to installing the update. Everything started well within 1 minute on my 11mb connection.
Since the update, Netflix still works perfectly, previews still work perfectly. Only movie rentals have the long download problem. Unable to determine the time one day, 232 minutes the next... had to pause again for an hour 2/3's of the way through.
The problem is the Update, not DNS. Perhaps the update changed something about the way ATV2 uses DNS, but it doesn't change the fact that the root problem lies somewhere within the Update.
By the way, if you read the thread on Apple support, you will see that people with both ATV and ATV2 in the same household only have the problem on ATV2.
And people who take their ATV2 back and exchange it for one with the previous iOS version don't have the problem anymore.
You, sir, are absolutely correct. I find it amazing that I've seen this posted on a lot of "techie" websites, you would think that a WEBSITE would know how DNS works.
The only reason adding Google DNS to your list of servers would speed up web browsing is it helps your computer find all the links to all the Ads posted on the webpages, so your page finishes drawing faster.
Add this it helps even more!
http://safariadblock.com/download/
As many have already said, this article is misinformed on many levels, and shows that the author doesn't really understand DNS at all.
1. DNS is simply a directory for matching human-readable names (i.e. apple.com, cnn.com, yahoo.com) with an IP address that computers understand. It doesn't have ANYTHING with setting routes (or "paths", as the author states) to/from your computer and the site!
2. the point of third-party DNS services, like Google or OpenDNS, is to speed up your surfing-- these servers are typically dramatically faster-responding than your usual ISP. Switch, and you'll see the difference.
3. Once your computer has connected to a site to download, stream, etc., DNS has no role in that process. A DNS server WILL NOT affect your download speed!
4. it is trivial for a company to block users from setting their own DNS-- simply block port 53 on the firewall (except for your main DNS server, of course). Any user setting their own DNS to anything other than the corporate DNS will be surprised to find they can no longer surf the web.
Although this article doesn't clearly identify what the real inefficiency is caused by this problem, it does exist and due to the way Akamai operates and it can have an effect if you are not using your ISP's name servers.
When you send a query for a web site to your recursive DNS server, usually your ISP's, that server in turn will query the CDN's DNS server(s) after recursing from the root zone down to the appropriate TLD zones and possibly other zones until it lands on the CDN's DNS server. Now that server doesn't know who initiated the query, but it knows the IP address of the recursive DNS server where the query came from. That CDN, Akamai for example, can have a database of IP's mapped to locations. Based on this, they will typically respond with a geographically close cluster of servers to the originating recursive DNS server. It's assumed the client who made the query to the DNS server in the first place is also reasonably close. That's where the problem can come from.
Certain recursive DNS servers also actually give you different results. OpenDNS for instance gives you a different result for google.com than most of the Internet. This is specialized for them. The purpose of that I'm not entirely certain.
Anyway, if the server you are told to connect to ends up being geographically further away, the latency is higher in reaching this server. Due to the way TCP functions (without specialized techniques like negotiated window scaling on both the server and client side), throughput is directly correlated to the latency in reaching that server. TCP is a reliable protocol, so there is an acknowledgement for each packet that is sent. If the latency is higher it takes longer to send the same number of requests and acknowledgements in the TCP stream. You can equate this to transporting boxes in your car between two towns. If you have 100 boxes to transport and can only fit 10 in your car at a time, that's 10 trips. Now if you're going between two towns that are 10 miles apart vs. 20 miles apart, it's obviously going to take you longer to transport all 100 boxes between the towns that are 20 miles apart. Equate the car to a TCP packet, the boxes to data and the miles to latency. If you got a larger vehicle to transport the boxes you could fit more and do it in less time even if the distance is further apart. This is equated to TCP window scaling.
So, all things being equal, your throughput is limited by the inherent nature of TCP and latency. I had a formula for this one time where you could calculate it exactly but I don't have it handy. UDP isn't bound by this restriction as it doesn't do any checks that data has arrived. This is why it is often used in DDOS attacks (besides the fact that it is easily spoofed). You can easily flood a pipe of any size with UDP, but you have to write the software to handle the error correction and retransmission of lost packets.
So in the end, yes it does matter if you use a DNS server other than your ISP's and it can ultimately affect throughput as the CDN will tell you to go to the server it thinks is closest to you. Is this always a limitation? Absolutely not. It depends on how the DNS service is setup. If you're using Google for example, just because you query 8.8.8.8, that doesn't mean that's a single server in a single location in the world. It's likely anycast which means many servers around the world all use that same IP address. You are just routed to the closest one. What this also means is that the queries from that server CANNOT originate from that 8.8.8.8 address to resolve things. Otherwise the responses would go to the nearest server to the authoritative DNS server for the domain being queried and you'd never get a response. All the DNS servers also have unique IP addresses that they source the queries from. It's likely that Google hasn't shared the IP information for their DNS service with the CDN's to optimally provide the best local server. Once that happens, this problem will likely go away, but Google tends to be very secretive with all of their internal network information.
Hope this helps clear things up a little and touches on topics that I believe should have been in the original article for completeness.
Also, for the record I don't use OpenDNS, Google DNS, or my ISP's DNS. I don't trust any of them because of the modifications they do to DNS results. I run my own DNS server in my home that I have complete control over, in addition to providing DNSSEC which I know my ISP's servers do not, and I'm unsure about OpenDNS or Google.
Well, I don't use Google DNS or Open DNS.
I use my ISP's DNS, which is Oceanic Time Warner in Hawaii.
My ATV2 worked perfectly for all of my movies prior to installing the update. Everything started well within 1 minute on my 11mb connection.
Since the update, Netflix still works perfectly, previews still work perfectly. Only movie rentals have the long download problem. Unable to determine the time one day, 232 minutes the next... had to pause again for an hour 2/3's of the way through.
The problem is the Update, not DNS. Perhaps the update changed something about the way ATV2 uses DNS, but it doesn't change the fact that the root problem lies somewhere within the Update.
By the way, if you read the thread on Apple support, you will see that people with both ATV and ATV2 in the same household only have the problem on ATV2.
And people who take their ATV2 back and exchange it for one with the previous iOS version don't have the problem anymore.
i agree with this, although i'm having issues with all forms of downloads with the 4.2.1 update for ATV2, google dns or otherwise. worked perfectly out of the box, updated and then crippled.