DNS Error Page
This is not a big deal at all! I know those that wear aluminum foil hats are screaming bloody hell but let's look at this realistically!
First and foremost, the average user is not so savvy. This service will be GREAT for them and actually help them find the sites they mistype and so on.
If Verizon is smart they should take this DNS service and create what OpenDNS offers ... the ability for the Verizon users to log into a control panel and block certain domains such as porn, whitelist sites and blacklist others and track their DNS stats.
On a technical standpoint this service will NOT affect clean DNS. You will ONLY get a help page if the site you try to find does not resolve to an IP!
For the likes of the trio from The X-Files, users can OptOut from this service.
For those that are technical minded and likes what Verizon is doing in regards to help pages, consider checking out the OpenDNS.Com service as it does what Verizon is doing and much more! You can block domains, block porn, block phishing sites, track your network stats and much more.
In regards to advert revenue, great idea Verizon .... extra revenue from such things like this helps to keep package prices affordable for subscribers! Why would anyone cry that Verizon is making money from advert revenue? Someone short the stock or perhaps a Comcast employee is mad they didn't think of it first?
In conclusion, the consumer group that is barking about this service first needs to hire someone that understands what DNS is before they comment on something they certainly do not understand. Verizon is trying to implement a service that will help average users, not tech savvy people like you and I ... the people that browse DSLReports.com ... but the people that call YOU up when their MS Word document disappears from their desktop... .the average user! That said, the service is even helpful for geeks as it confirms the DNS service is working and that for sure the web site they tried does not resolve.
Then there is the observation that the Internet is a WHOLE lot more than WWW. Corrupting DNS like this breaks non-WEB applications that expect to be told a domain does not exist, and have nothing to do with fumble-fingered users. If the ISP wants to capture mistyped browser addresses, then provide a customized browser or browser plugin for their customers that does that redirection. But don't mess up core Internet functionality.
You make a good point that I didn't think of at all when assessing this. If non-WEB apps get confused by this, that could be an issue.
That said, I have been using OpenDNS for a while and have had no issues that I can speak of but I can see where you are going with this. Would this system interfere with non-HTTP requests or is this system smart enough differentiate traffic? Hypothetically, if an app is not looking on port 80, this system should be able to bypass the "help" pages.
I just did an experiment, »www.verizon9237i344534hkd7.net:8047/
and instead of the interactive error page I received a normal generic "Could not connect to server" error which tells me that at least OpenDNS ignores non port 80 traffic in whole regarding their interactive error page.
For you that are using the interactive Verizon DNS pages, try this url and »www.verizon9237i344534hkd7.net:8047/
and if you don't get a verizon error you are confirming it is ignoring non-port 80 traffic. This should conclude that this system should not interfere with non-http traffic and apps.
The port is not part of the DNS system. You just give the DNS server the string and the record type (usually "A"), and it returns some number of IP addresses. The server has no idea what port you intend to connect over once you get the IP address(es). The URL you stated just says to find the IP address associated with that fake name, and then try to connect to it on port 8047. I am willing to bet that that their broken DNS server returned the IP address of their "help" server, but, as expected, that server isn't listening on port 8047, so you get the error you saw. Note that you got "cannot connect to server", not "server not found".
I am trying to figure out an easy way to test and see if the interactive DNS will interfere with non-http apps or not. I know the port number has nothing to do with DNS, however, does the interactive DNS have something to do with ports? In other words, does OpenDNS and the Verizion "helpful" DNS know that you are requesting DNS lookups for a port 80 request and if so, will it bypass the system completely for non- port 80 traffic? How smart is it?
The "Cannot connect to server" error is an Opera error equivalent to "Server not found" in IE.
I tested the fake URL & a real URL with a random port using IE and this is the error:
Cannot find server or DNS Error
Do you have any suggestions in hwo we can test this "interactive" DNS once and for all. I am very curious to see if it interferes with non-http apps or not.
How about running ftp (instead of a browser) to various sites? That's a nice non-HTTP application. It should give "unknown host" for a non-existent host name.
|reply to JohnNWPVNJMH |
That error message you see in Opera and IE are not the actual error messages from the DNS server. The actual errors are error codes such as "404". The actual message you see in your browser is just a result of how Opera or IE decided to handle a 404.
You could try wget, which is a linux method of retrieving http data from a command line. There is a windows version of it. Its very widely used and would likely be adversely affected by this Verizon shinanigans.
400 - Bad request
401 - Unauthorized
403 - Forbidden or Connection refused by host
404 - Not Found or File Not Found 404 errors are among the most common error messages on the Internet.
502 - Service Temporarily Overloaded
503 - Service Unavailable
The friendly HTTP-status error messages are stored in the following registry key:
Internet Explorer 5 and later provides a replacement for the HTML template for the following friendly error messages:
400, 403, 404, 405, 406, 408, 409, 410, 500, 501, 505
There is a name value pair (for example, "404", 128) for each of the errors. The first value is the error code. The second value is the byte size value used by Internet Explorer 5 or later to detect when it should replace error messages with its own. Therefore, when the Internet Explorer 5 version of the Wininet.dll file obtains an HTTP error message, the Wininet.dll file determines if the HTML content attached to the HTTP error is a well designed Web page. This is based on the size of the page. The threshold value in the registry is evaluated for each error. If the Web page is small enough, it gets rejected, and the friendly HTTP-status Web page is displayed.
|reply to JohnNWPVNJMH |
I tried various real and fake FTP addresses and had no problems with OpenDNS server interfering. This suggests that the OpenDNS service is smart enough to know the difference between HTTP requests and other. Someone may want to check this out using the Verizon DNS servers and see if they get the same result. If so, we may be able to finally debunk the idea that helpful DNS will interfere with other, non-HTTP, apps.