Hello everyone,
There seems to be a bit of mis-information going on in this forums post with regard to what is happening and how DNS servers work.
Oh, I use the term "OP", which stands for "Original Poster". Terms wrapped in tick `marks` represent command line tools, and references to running command in to terminal mean to copy those commands, making sure to not copy a trailing return, paste them into your terminal, and then press return. Here is an intro to the Mac OS X Terminal ( http://bit.ly/OhZdq4 ).
To avoid any bad feelings, this is just information, and I am just trying to help as rapidly as I can, I am not replying to anyone in particular, just answering the general sentiment of most posts in this thread.
First, the OP is having an issue with autocomplete of the TLD ( Top Level Domain's ) in Safari. It was mentioned that it is surprising that it is slow for him as his Internet connection speed are fast. However, you could have 1000Mb/s downstream and upstream and still have slowness issues if it were DNS related. ( Or not DNS related )
If the OP's upstream data connection is swamped, meaning his ability to upload data is at full capacity, that will not leave enough TCP/IP overhead for most, if any downstream requests to happen. This could cause slowness in all locations, not just DNS.
If it is DNS related, a swamped upstream could cause certainly part of the issue.
If the upstream and downstream have adequate bandwidth, there still could be problems. The large majority, 99.9% or better perhaps ( pulled that out of my booty ), of all DNS requests do not happen over TCP, but over UDP ( http://bit.ly/OhY2Hf ). This is by design — while UDP is not as robust a protocol for error correction, it is much better suited for something like DNS where the returned data is usually of a relatively fixed size and error free.
Internally, Mac OS X, or any other OS more than likely does not use `dig`, `nslookup`, or any of the "bin" tools users have access to on their system. It is more along the lines of how you would do DNS resolution if you were to need to do so in C, or in the case of most Mac OS X desktop applications, Objective-C. Regardless, this beyond the scope of an answer for this forum question.
The OP has an ISP that is clearly doing "DNS hijacking" ( http://bit.ly/OhZYzp ). This could be proven with `dig` ( Command line based DNS lookups and resolution tool similar to `nslookup` ).
Make up a domain that you know does not exist, such as http://dsajewqueyudgs2321.com and open your terminal — enter in
`dig` dsajewqueyudgs2321.com +trace +norecurse +short
The results you should get will be a list of what are called "root servers", usually 10-15 lines starting with letters of the alphabet ( just a user decided naming convention ),lead by "NS" ( NameServer ), followed by the lookup server's IP address and finally how long it took in milliseconds. Something like this:
NS a.root-servers.net. from server 8.8.8.8 in 20 ms.
NS b.root-servers.net. from server 8.8.8.8 in 20 ms.
NS c.root-servers.net. from server 8.8.8.8 in 20 ms.
NS d.root-servers.net. from server 8.8.8.8 in 20 ms.
NS e.root-servers.net. from server 8.8.8.8 in 20 ms.
This result tells us a few things. First, that my ISP is not doing DNS hijacking, because I am getting root servers returned. In a DNS hijacked situation, you would see an answer that more than likely contained NS's with domain names that sound like your ISP, or something like:
dns-ad-server.brightcable-annoyance-server.com.
To see if the OP's issue with the time of how long it takes Safari to figure all this out, you could also use `dig`. I would imagine this lookup order is hard coded into Safari, and does not live in a plain file anywhere. This would be done for performance and security reasons. That text file would be a great security attack vector to cause some very interesting and confusing results to an end-user.
To test the time, perform `dig` lookups in order to get to a .org
dig example.com | grep msec
;; Query time: 21 msec -- result, do not paste this in…
dig example.net | grep msec
;; Query time: 21 msec -- result, do not paste this in…
dig example.org | grep msec
;; Query time: 21 msec -- result, do not paste this in…
In this case, I ask `dig` to look for example.com/.net/.org and pipe ( http://bit.ly/Mpyhkj ) it through `grep` ( Unix tool to find data in strings using pattern matching or regular expressions ) to find the line that tells me how long it took. So for Safari — to run through a worst case — where there was no .com, no .net — and finally — a resolving .org — would take a minimum of 63 milliseconds. Pretty fast!
The OP chose to use openDNS ( http://bit.ly/Oi21DH ). This is fine, and in some cases better. One thing openDNS does is tracks your IP address and allows you to define settings based on it.
If you don't create an account, it should do nothing. However, if someone else has ever "owned" your IP, you would inherit their settings if they set the account up. You can set up shortcuts in openDNS — as well as many other options. So you could instruct openDNS that when you type in the single letter "g" into Safari it takes you to gmail.com.
If you don't configure openDNS, it would take you to g.com if that exists, g.net if the prior didn't exist, and g.org if that prior doesn't exist. In Safari 6, it will finally perform a google search for you. I can't seem to think of a condition in Safari 6 where you would ever get to a "Safari can't find a connection" error page unless your connection really was down.
If I am in a case where openDNS is fastest, which I will determine through testing openDNS against Google Public DNS, using `dig` as my time metric tool, or using http://code.google.com/p/namebench/ and testing a ton of public DNS servers. It can often depend on your location, but not how most people think ( More on this later, it is called 'anycast' http://bit.ly/MpyWlQ ), but will also depend on line speed, latency, DNS Server speed, time of day to determine user load, and a handful other variables that have to do with caching and TTL's ( DNS Time To Live Settings ).
If the OP continues to use openDNS, I would at least login and create an account to make sure he didn't inherit someone else's DNS's configurations. This has happened to me before where clients will have well known domains, or single letter slips end up at adult sites, "internets", private domains, and other locations that should be secure by more than public visible DNS obscurity ( Even if you have DNS +xfer disabled. +xfer allows one to download a list of all DNS entries. ).
Google also has free DNS servers to use, and as a general rule of thumb, I find them to be around the fastest, or fast enough, and the IP's are simple to remember, just an 8 in dotted quads and a split 8 and 4 in dotted quads. So 8.8.8.8 and 8.8.4.4 . Not that openDNS is that hard to remember either.
One user here is using his own DNS server locally. This can easily be done on the very machine you use as well, this would be the fastest, by removing any network delay at all — but can't take into account the popularity of openDNS and Google Public DNS's massive user base contributing to their caches — not to mention that openDNS actively NXDOAMAIN's ( http://bit.ly/MpzUOQ ) phishing and fraud domains so you can't accidentally click on a bad URL. The problem is that more than likely this will slow things down more than speed them up. The advantage of using openDNS and Google public DNS is that so many people use it, just about every domain out there is already cached at their DNS server, at least until the TTL ( Time To Live ) value expires.
If the OP is getting results of the Bright House search page, regardless of whatever DNS changes he has made, they are not working. openDNS would not return those results, and any true NXDOMAIN, aka: no domain exists, would cause Safari 6 to perform a search using your default search engine setting. Pre Safari 6 will yield an error page.
Google's DNS servers are not 4000 miles away no matter where you live and no matter where their data centers are. Nor are openDNS's. Both have far more than a few servers handling this level of load. Even companies like reddit, apple, facebook, etc. more than likely will not manage their own DNS. They contract out to openDNS or other major DNS CDN resolver outfits.
This is for a few reasons. One is the 4000 mile issue mentioned. If I live in the USA and someone else lives in Europe, and is using Google Public DNS, that does not mean their DNS request must travel 4000 miles even though they only use one IP address. openDNS and Google Public DNS, with only one real IP, doesn't mean they are doing some fancy load balancing all in one datacenter making all requests take such a long trip.
The avoid this by using something called anycast, which allows a single IP address to sit anywhere it wants physically in the world, on as many servers as desired. I can trace to 8.8.8.8 from my location and I go from home to Mountain View Pretty quick. In this case, I do in fact hit their home data center. But if I hook into a VPN in Japan, and trace to 8.8.8.8 I, slightly slower, go from home to make my way to Tokyo, where google seemingly has a datacenter — or deal with someone who is allowing them to resolve 8.8.8.8 and 8.8.4.4 to their DNS infrastructure.
As a side note, if you need to test DNS lookups using `dig`, it will default to using the same DNS server your browser is going to use. If you want to force `dig` to use a specific DNS server, you will have to use the @ directive in `dig`:
`dig` example.com @8.8.8.8 +norecurse`.
The OP should first try entering in 8.8.8.8 and 8.8.4.4 into his TCP/IP settings in the Network Preference Pane of System Preferences. It is in the "Advanced" button, under the "DNS" tab. You should also see in the Network Preference Pane, in the main window, your list on the left that shows your network interfaces devices. Since I am on a laptop — and never use wired Ethernet — never use FireWire as a network connection— I have deleted all other entries aside from those that I need. The list on the left is usually Wifi, Firewire, Ethernet, Bluetooth, and a few more I am probably forgetting — can slow things down as well — as it is a list that on some occasions, such as toggling an active VPN — will have to be scanned through. So delete those that you will never use. You can always add them back in through the small gear and triangle icon.
You should also "Set Service Order" which is done with the same gear and arrow icon. Just drag them around to set the order of precedence. In my case, wireless is first, in other cases, Ethernet may be first for some. Close it all up, save the settings, and do a search for known non existent domain ( NXDOMAIN ), you should, in Safari 6, get a default search engine page, and not the ISP's DNS hijacked page. In this OP's case, he should not see the Bright House page. Some code people have written relies on there being a NXDOMAIN response, and is part of RFC protocol. Bright House has inadvertently ( Or Intentionally ) broken all those applications.
OP may want to login to his ISP's control panel and make sure he can't turn this "feature" off within their settings, or even define his DNS servers at their server level. The worst would be if it is hard coded into their Cable Modem or DSL modem. And if that modem was a router that you are using. In that case, you will need to go buy a router of your own and make sure that you are connecting to that router. You may even have to buy your own cable modem, which they will not particularly enjoy supporting. Something like this:
ISP's modem/router -> Your new router -> your computers on wifi or wired.
If you already have your own router, which I suspect you do, you may need to add in the DNS IP's within your router, at which point, you should see your TCP/IP settings on Mac OS X within the Network Preference Pane of the DNS tab reflect those IP's in a greyed out color that is editable. You can still add even more to fall back on for this particular machine. For example, have the primary Google Public DNS Servers in your router, and add AT&T's Level 3 Public DNS IP's as a fallback so that if this is a laptop, you know you are using somewhat known and trusted IP's. ( I know, AT&T and known and trusted in the same sentence… I should just delete this entire post as I just nullified it 🙂 )
If you still can't get your machine to recognize the DNS lookup IP of your desire, I would call and get angry 🙂 , start looking for a new ISP, or really start digging deep into your system. First would be to perform a traceroute to some known location and see what devices your requests are hitting. The culprit is probably the first one. But again, if it is cable, and set within the modem itself, the CMTS ( Cable modem Termination System ) may be holding those values, in which case, `traceroute` may not show this device, and there may be nothing you can do about it.
OP: on the Bright House page, is there anywhere that says "disable this search page" or similar? Comcast tried to do DNS hijacking, calling it an add-on feature for users. Users revolted and Comcast had to add a disable feature on the pages. Perhaps you do as well. If Bright House is also RoadRunner, they most certainly are DNS hijacking: ( http://bit.ly/MpCbcI )
What is scary about this, is the assumption that they are logging and selling this data. They know what domains you go to that don't resolve, so they know what domains are most popular that don't resolve, meaning they know what domains to buy and specifically market the content their end users. And they know what domains you do go to, so they know more about you than they should. Accidentally get on some **** that they deem too offensive, young, disgusting, etc, and you could end up with a fine, Internet terminated, jail, unemployed, and otherwise guilty until you prove your innocence.
I do tend to agree with OP, at least on Safari 6. Pre Safari 6, everything worked fine where I didn't bother with the www. or the .com, it just "worked". But now, when there is no domain, I get a google search. I'm sort of OK with this, as it doesn't affect `dig` and other closer to the wire network tools ( As far as I am aware ), just a browser, but imagine if it trickled down to ftp, ssh, etc, — one single keystroke and I am sending a ton of data off to the wrong place. And it is being logged!
In summary — OP: enter in 8.8.8.8 and 8.8.4.4 into your system, unless you want to enter it into your router so every computer that connects to your network need not be modified. Entering into your router is probably best. When you do so, you should be able to open your DNS tab and see those IP's in a slightly grey color. Mine looks like this: http://i.imgur.com/OHMF2.png
Another thing to consider, is it is common, and arguably becoming a best practice for Search Optimization Reasons to drop the www entirely. This doesn't mean that www.example.com won't work, it just means that www.example.com hits the remote server, sees there is a www on it, strips it off, and redirects you back to example.com with no www's. There is another slowdown just introduced, and this one is out of your control, is the remote servers system that is in control of, and can also be "heavy" on the server — if it has to remove the www off of a url like:
http://www.example.com/foo/bar/page1/article1/story1.html?color=red&day=oldest&s ort=new and convert it to:
http://example.com/foo/bar/page1/article1/story1.html?color=red&day=oldest&sort= new
OP, your worry about speed because you can see the blue bar doing it's dance. I can almost assure you it is perceptual. Safari is generally faster at page loads. It may not "feel" that way, but time it down to the millisecond and it is. Tests have been done where a plain blank page is shown, then the entire webpage is show and in in as much as ~25% sooner than incrementally showing the page, slowy loading graphics and other resources over time. Near all users will say the ~25% slower page is actually loading faster. You are focusing on the progress bar, but a lot is going on in the background that you aren't focusing on, and rightly so, you shouldn't have to. In the end, you should be getting a result that is faster than most other browsers — though it is marginal, we are talking 20's of milliseconds here.
If you go into your preferences in Safari, you can turn on the "develop menu" which will allow you to open up the "Web Inspector" as seen here: ( http://bit.ly/O3SW0b ).
FireFox also has FireBug, an extension that can perform the same test, and Chrome, being based on WebKit, also has the exact same "Web Inspector" built right into it as well. So you should be able to see the exact times.
If you just want to test the time to load a page, without loading any external resources like images, JavaScript libraries, remote resources, etc, you can open your terminal and run a test:
time curl www.apple.com -o /dev/null -s
real 0m0.136s
user 0m0.009s
sys 0m0.005s
time curl apple.com -o /dev/null -s
real 0m0.212s
user 0m0.008s
sys 0m0.005s
`curl` is simply a command line tool that can download, amongst many other things. It usually prints it's own time's, but these results are too fast for the lack of precision in `curl` so I am piping them to the `time` command which has more precision, and then sending the resulting data to nowhere ( /dev/null ). This is adding in a small amount of time for writing a itty bitty bit of data to disk for a split second, but it is millisecond marginal. ( Actually, I'm not certain that sending data to /dev/null has disk I/O or not )
I did one to apple.com and one to www.apple.com so you can see in apple's case, the add back in the 'www' — which takes time — it took only .136s to load www.apple.com — but took 212s to load apple.com — then look at the URL, decide to add in the www, and return a result. So I get your point, in your case, adding in the www and com was faster, but aside from apple and google and most older sites, many sites are removing the www and just going with the straight and plain domain name.
* This is an impure test, network overhead, available bandwidth, other applications, and many other variables will never be the same from one test to another. But it gives a rough idea that is very accurate for our testing purposes. Basically, even if you don't change the url, you will never get the same result twice when deal with fractions of a second like this.
It seems Bright House is RoadRunner, so I did this search: http://bit.ly/OkaRRj
( Bright House Cable dns hijack workaround )
You may want to read up there some.
This looks promising, and then it starts to look non-promising:
( http://bit.ly/NN6Hz3 )
Here is another:
( http://bit.ly/NN6Gex )
And one more:
( http://bit.ly/NN6GLx )
Oh, and OP, you will get used to it — and I bet over time — you will like the way it works. Just in writing this, I have used Safari 6 for only as long as it took to write this. I am already starting to like it better. One issue is it is a oddly hard task to get the google search url of the page you are on. I also don't think the changes you are seeing in the address bar are Safari working out what to do, but the remote server is working out what to do. With every web-page using so many ad networks, and doing so much user tracking and analytics, it is not uncommon for a page to jump around 10 or more times before it gets to where it was supposed to go. Many of those ad networks further look up your IP and then your location. If you look in Safari 6's preferences, there is a new setting designed to combat just this scenario, ( sort of ): http://bit.ly/N1CBWd
For your PC at work, you may need to define a "default search domain", or dig deeper. *nix is my specialty, and I try to stay away from windows and even on the Mac from the GUI, spending most of my days doing some form of lite system administration.
After watching the OP's video, it is pretty clear to me that this is in fact a DNS issue. I wish I could have seen a third page load on apple.com. First was slow, second looked to load instantly, and I bet the third would have too. If for some reason ( system update, Safari update, bind/named update, Safari DNS cache clearing ) your local DNS cache may have been cleared. That would slow initial lookups down by a large degree. Your page load times are very fast, it is just that initial lookup. It could be that there is a Javascript library, such as jQuery, which pretty much everyone and their mother has in use on their site these days, and is hooked to one of many CDN's ( Content Delivery/Distribution Networks ), which is no longer cached, is a rather large file, and will halt all page loading until it is in fact cached. Or that CDN is having some issues that just happened to correlate to your testing. If you have never seen the Bright House DNS hijack page, either they just rolled it out in your area, which explains much of this, or you did a software update that nuked your DNS cache — which also explains a much of this.
I would be interested in what `time curl apple.com -o /dev/null -s` reports. I would bet it is near instant. At that point, you need to start looking into the Web Inspector and see what item(s) are slowing things down for you. I bet there is a commonality. It could be as simple as Bright House is overloaded, or they are blocking certain URL's for "your own good" reasons and Safari has to timeout those DNS lookups, which just so happen to be early enough on in the page load cycle that Safari has not yet been allowed to load any page content. This would explain why Google's Public DNS is slightly better, but the problem still exists.
Another thing to consider, is Safari also has an extension API, and there are a ton of extensions 3rd parties have made. while I wouldn't go too crazy installing hundreds of them, as you can easily overload anything, a few 10's of them won't hurt a thing. I would bet there is an extension that will add the keyboard shortcuts you desire, and even offer some customizability.
For me, I would want to first get to the root of the problem, find out why your DNS, or whatever it is, is causing these slow-downs, and then look to finding a way to add back in the behavior you desire. Or just use Chrome, it has the same backend as Safari, though tends to release a little slower from what I last recall. But again, I would want to get to the root the problem first. This page proves to me the extension is technically possible: http://bit.ly/NN70Kf
If you can't find an extension, you may try making one yourself, I an assure you, this would not be hard to make. If you want it really bad, head over to scriptlance.com and pay someone to make it, I bet $25-$50 will get you there. This is close, adding keyboard shortcuts to lots of options, I wonder if a quick, nicely asked email and a donation offer might inspire him to add such support: https://sites.google.com/site/solushex/keystroke
Apparently Apple considers the HE double hockey sticks a word worth striking out.
