Did we really need that response twice in a row?

I'm not sure if that reply was meant for me.

But if it was then yes, you do need my reply.

The thing that screws it up with an airport extreme and a osx machine is that osx will list the airport as the first DNS server. The airports lan IP is also greyed out, so that it can not be removed. This in effect means that entering more dns servers will not help you unless you make sure that the airport isn't able to process any dns requests, because osx will make dns requests to servers in the order they appear on the list found under systempref.->network->advanced->dns.
The dns requests to the airport can be made faulty by altering the DNS IP's listed under the Internet tab in the airport extreme, the IP addresses are greyed out but just click on them and enter the airport wan IP in both primary and secondary DNS.
When this is done osx will, when looking up a web address, first contact the airport router, the airport router will relay the request to the IP entered in its DNS config. This will however make it contact itself and the request will be denied at once, osx will then move on to the DNS server listed as the next one, this then does not involve the airport router because request are made directly to dns server. Speeding things up drastically.

Haven't seen this solution offered before, but i sure works for me... I even entered the same DNS IP addresses in osx as the airport was using as default.

Something happened with Mac OS X's low-level DNS resolving functions during the development of Leopard and now a variety of applications are screwed up. I'm also seeing this problem, as well as the "slow SSH problem." I think we're just going to need to wait till Apple does something about it. Since the problem appears to be somewhat dependent on what kind of servers are running on your network, this was probably not something they could figure out during the Q/A phase of finalizing Leopard, tho I'm surprised the Beta seeds didn't reveal this issue...

Related to "slow SSH connect" issue with leopard:
see http://discussions.apple.com/thread....55437&#6655437

See this page

http://blog.jungledisk.com/2007/10/3...d-work-around/

I've put together a simple and hopefully easy to read guide for this over on mac-forums - http://www.mac-forums.com/forums/sho...d.php?p=607373 but basically all that you've gotta do to fix the problem is bypass any automatically assigned dns servers on any routers or modems on your network, then specify your own ones (eg opendns, or your isp's ones).

My wireless on my MacBook Pro is so slow it is doing my head in.....Apple are ignoring the problem.....IMHO!!!!!!

I am currently sitting 2 metres away from router. I use WPA2 security but it exhibits the same behaviour with any type of security to no security.

It takes 15 second to load macosxhints on wireless and 2 seconds on ethernet of course i clean the browser cache to do the test and flush DNS. This is also reflected in DNS lookups so it is not a DNS issue.

This PROBLEM is going on on many Intel Macs i support as well as my own....on 10.4.11 and 10.5.2. I have done extensive testing on many systems and routers and i can confirm that the Atheros driver is CRAP and/or apples implementation of IO with kext.

If it was just my machine i would think hardware problem but nay.....it is at least 20 to date out of 100 machines i support. All the older broadcom based machines/PPC are perfect no problems on the same network.

The problem is also compounded by moving from battery to power adapter which can in fact lead to the wireless just not working at all for a while.

Apple once again pull your iphones out of your arse and sort out core issues out !

And yes i have posted on apple forums but had my posts deleted very promptly even when just explaining what was going on, and not using any derogatory comments....so a big THANKS to Apple for listening to their consumers.

Ah the wireless age.....better hope the Macbook Air has a good wireless chip/driver or you are right in the crap.

You aren't being clear enough. Is DNS slower over Airport than over Ethernet? If so, is the slowness of DNS enough to explain the slowness of web-apge loading?
(It's be better to remove DNS from the equation by loading web pages via IP addresses instead of names.)

Please post your evidence, not just your conclusions.
In particular, I'm interested to see how you have identified this as a driver problem rather than the other (much higher-level) software.

Every time i am on wireless DNS lookups are slowwww and when on ethernet very fast. I use openDNS on our network and it has been working very well with all other machines.

On another network/site i support i have managed to nearly remove wireless from the equation on all intel machines as they ALL were exhibiting the same issues......slow WIFI, lack of comms to router, slow DNS, not being able to connect to network with authentication failing and just not connecting to the network.....the dreaded "try again". One thing that helped the authentication was changing the wireless channel from 10 to 9 then back again.....just weird. This is mainly with Macbooks/Macbook Pros but some iMacs as well. The fact that NONE of PPC machines have any wireless issues does point to something with driver IMHO. Most machien sare on 10.4.11 and a few on 10.5.2. All machines that are wired are fine anything(intel based) on wireless appears to be alright but they throw up one or more of the symptoms every other day...

In answer to evidence.....
I have no real evidence apart from the fact there have been 5-7 revisions of the driver/IO80211.kext in 18 months which shows something is up IMHO. This coupled with the fact the same machines while using bootcamp (XP) have no issues at all. So its not hardware !

Try turning on the UNIX Name Service BIND (Berkeley Internet Name Domain) via root terminal. It's built into OSX (as OSX is UNIX based) but off by default (not sure about Leopard) for some odd reason, but it's the UNIX native DNS. Well it's actually a suite of UNIX based utilities including nslookup and dig but contains a very good DNS server that may fix your problem if it's DNS related.

F21 if you are referring to my comments....it is not practical to have the 20 client machines running a local DNS server and having a main DNS server on network as well.....so it will not help.

As far as running on my own local machine, i have reasonable experience with DNS setup so may have a go, but something is up with the WIFI.....full stop.

Since rolling back Airport/IO80211.kext drivers to the 10.4.9 version things have been better coupled with my laptop pinging router every 2 seconds....not ideal but it is keeping things mildly in order.

Found solution to slow internet; haven't seen it listed here yet
 

I was experiencing what a lot of folks have experienced: very slow internet as soon as I upgrated my Mac (mini) to Leopard. All the speed tests I ran off of the web showed good speed, but it did appear that the problem was not in the downloading but in sending the request to the site.

I ran all of the suggestions above to see if they made a difference. No difference.

So I went into my DSL modem settings and looked for settings that would affect look up. I found that it was *not* the particular sites it was looking for, but *how* it was looking: "Dynamic DNS". I changed the DSL model settings from Dynamic to Static DNS, and kept the two IP addresses listed the same. So instead of dynamically trying one and if not working, try the other, it was doing it as a static list (which, parenthetically, is similar to creating the static list in unix for lookups).

Once I restarted the modem, my total internet speed (DNS lookup + download) is back to fast.

My interpretation is that the Mac is asking the DSL modem and is somehow lagging poorly when the model does the dynamic lookup.

Hope this helps.

Mark

routers gone wild... on SRV DNS requests
 

ssibayan & eightmedia:

You're likely right with regards to routers being at fault with respect to slow internet access under Leopard. Many routers don't respond to SRV DNS requests. And this is the type of DNS record Leopard asks for first, before retrying with A record requests after multiple failures/timeouts on SRV record requests.

Switching to a different router that does handle these requests, can make a large difference in browsing speed, which is exactly what you're seeing.

Same goes with IPv6 DNS requests (if you're using Firefox).

opendns' misleading instructions
 

drsmartz

I just took a look at those instructions from opendns on changing DNS servers and ... that's not going to help anyone having slow dns lookup issues on Leopard.

Simply adding DNS servers onto the bottom of the list will still have Leopard asking the first DNS server to perform the domain name lookups. Only after the first server has failed the lookup or timed out will Leopard try the second and third.

To add to the misinformation, those instructions are for Ethernet only. AirPort, and every network device for that matter, has its own set of service settings. Thus, if you're on AirPort wireless, adding DNS servers to your Ethernet interface is like changing tires on your bike and hoping your car drives better. Don't think that'll be very helpful :rolleyes:.

If you look closely at those screenshots, the guy who made them is using AirPort wireless, yet he wrote instructions on how to change DNS servers for the Ethernet device. He and everyone else on wireless using those instructions will see zero effect from those changes.

To add OpenDNS' servers to your DNS lookups on wireless (or Ethernet) and to actually make it useful, create a new Network Location and edit the device settings there.

I started to write instructions on how to do that here, but it's turning into a monster post. Here is a walkthrough with screenshots on adding DNS servers in Leopard to get around slow name lookup/Internet problems.

Just for info the first DNS servers inquired are those at the bottom of the list (normally added manually, as OpenDNS). This for sure if those at the top are grayed. Seen with Wireshark packet trace and Camino.

tcpdump says otherwise (I think)
 

I not sure if I can confirm what you say, arbushell, although I'll confirm tomorrow.

According to tcpdump, this is not true. The order that DNS servers appear in the list, from top down, is the order that the servers are used.

The greying out of servers simply means they are not removable from the list, not that they are "unused".

Another way to tell is by looking at service order using ncutil or scutil.

Again, will write more later.

For arbushell - order of dns is as you see it
 

Setup tcpdump as follows: sudo tcpdump -i en1 -s 128 port 53

(use en0 if you're on ethernet).

Open up another terminal window and enter this:
curl http://wiifit.com

This will load the web page using "curl".

The following is a printout from tcpdump showing resolver1.opendns.com as the DNS server.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 128 bytes
21:09:25.347972 IP 192.168.1.132.52104 > resolver1.opendns.com.domain: 8973+ SRV? _http._tcp.wiifit.com. (39)
21:09:25.413867 IP 192.168.1.132.52105 > resolver1.opendns.com.domain: 51611+ PTR? 222.222.67.208.in-addr.arpa. (45)
21:09:25.468237 IP resolver1.opendns.com.domain > 192.168.1.132.52105: 51611 1/0/0 PTR resolver1.opendns.com. (80)
21:09:25.471433 IP 192.168.1.132.52106 > resolver1.opendns.com.domain: 51254+ PTR? 132.1.168.192.in-addr.arpa. (44)
21:09:25.522641 IP resolver1.opendns.com.domain > 192.168.1.132.52106: 51254 NXDomain 0/0/0 (44)
21:09:25.644452 IP resolver1.opendns.com.domain > 192.168.1.132.52104: 8973 NXDomain 0/0/0 (39)
21:09:25.644965 IP 192.168.1.132.52107 > resolver1.opendns.com.domain: 49725+ SRV? _http._tcp.wiifit.com. (39)
21:09:25.698514 IP resolver1.opendns.com.domain > 192.168.1.132.52107: 49725 NXDomain 0/0/0 (39)
21:09:25.699892 IP 192.168.1.132.52108 > resolver1.opendns.com.domain: 38658+ A? wiifit.com. (28)
21:09:25.832046 IP resolver1.opendns.com.domain > 192.168.1.132.52108: 38658 1/0/0 A 205.166.76.53 (44)
21:09:26.526985 IP 192.168.1.132.52109 > resolver1.opendns.com.domain: 18132+ PTR? 53.76.166.205.in-addr.arpa. (44)
21:09:26.881751 IP resolver1.opendns.com.domain > 192.168.1.132.52109: 18132 NXDomain 0/0/0 (44)

And finally, attached is a screenshot of my DNS servers listed. Notice how 192.168.1.1 is listed after the opendns server, yet it's never even tried by Directory Services' DNS resolver?

I can't say everyone's Mac behaves exactly the same as mine, but, this is my evidence that DNS servers are used in order that they are displayed within Network Preferences pane / Advanced / DNS screen.

Camino and Wireshark are, in my opinion, far removed from the actual action of DNS lookup and thus are not good tools for diagnostics. Remember that Camino has a dns cache that it tries before asking Directory Services (DS), and if you've visited a site within the last minute, it won't ask DS to do a lookup and may make Wireshark produce ... misleading results.

What do you think?

Regards,
Ben

This link may explain part of the problem:
http://hunter.pairsite.com/blogs/blog20080603.html

cwtnospam
Wireshark (ex Ethereal) simply records and shows TCP and other kind of packets flowing on the connection and likely is layered over tcpdump, I don't think it messes the order of messages (I'm using WS on MAC just for continuity with Windows).
In any case I repeated the test with Safari and tcpdump, results are been the same: Leopard 10.5.3 (former test was with 10.5.2) sends the first A Query to the first non-router assigned DNS (that is the first non-grayed, in my case OpenDNS 208.67.222.222, set manually with networksetup -setdnsservers ... ....). The same happens with the terminal command 'dig' instead of Safari.
Very interesting the hunter.pairsite blog, probably most DNS issues are due to this comprised mine that in the past addressed me to try OpenDNS and other name servers available on the internet

Ah, 10.5.3 vs. 10.5.2
 

Arbushell, I think we may have just discovered something...

I believe Apple has reversed the order of the DNS server priority in Leopard 10.5.3.

I'm only speculating here as I have 10.5.2 installed and you have 10.5.3 installed, we're running roughly the same tests, yet you're seeing the opposite of what I'm seeing. Easiest explanation of that: Apple changed DNS server order with Leopard 10.5.3.

There is logic behind this from my perspective: If a user spends the time to add a DNS server manually to their TCP/IP setup, wouldn't they want it to actually be used?

The way Apple had it setup before (10.5.2 and prior), any DNS server you added would have no effect until the ones listed above it were tried/failed. Adding a preferred DNS server in Leopard 10.5.2 required creating a new Network Location, vastly more complicated then simply opening up the DNS tab and adding an IP address.

Anyone else able to confirm what order their DNS servers are used and under which version of Leopard? (Using tcpdump and curl as shown in post 56)
http://installingcats.com/wp-content...ns_servers.gif

Looking into the file /etc/resolv.conf (supposedly where DNS resolvers are stored) the manually added addresses are inserted at the top. Likely they will be later used top-down.
Maybe that the general rule is that the last added are used first. Such order in resolv.conf is surely true in my installation where the USB HSDPA modem control application creates a new Location every time a new connection is made ( this is a behavior causing unfortunately other issues!) and so the OpenDNS addresses can be added only when the provider-assigned are already in place. Perhaps when is used an existing Location the sequence with which addresses are written in /etc/resolv.conf is reversed. Or not?