Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Since upgrading to Mac OS X Lion (from Snow Leopard), I have noticed that resolving to a virtual host is very slow (between about 3 seconds). I have found a number of tips (e.g., not using the .local TLD) that might resolve this, but they do not apply to my setup.

My setup is quite simple: - Apache 2 (shipped with Lion) - enabled PHP - added a few virtual hosts - installed Mail and SMTP Pear packages

Apache's hosts file looks like this:

127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost
127.0.0.1   tbi.dev
127.0.0.1   www.tbi.dev
127.0.0.1   test1.tbi.dev
127.0.0.1   test2.tbi.dev
127.0.0.1   psa.dev
127.0.0.1   snd.dev

And Apache's virtual hosts file looks like this:

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/tbi"
    ServerName tbi.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/tbi"
    ServerName tbi.dev
    ServerAlias *.tbi.dev www.tbi.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/psa"
    ServerName psa.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/sandbox"
    ServerName snd.dev
</VirtualHost>

The setup is basically identical to my setup on Snow Leopard, but Apache's performance for resolving virtual hosts is significantly different. I run Mac OS X Lion 10.7.2, but the issue was already present when running 10.7.1.

This might seem like a small issue, but when you're accessing a virtual hosts a few hundreds of times a day then this adds up to a significant waste of time as you can imagine.

share|improve this question
    
I don't see anything in the problem description which has ruled out ordinary issues like system load, network utilization, memory utilization. You say resolving a virtual host is slow. From where? The host command, or viewing a page served by the server? If it is purely DNS/host related, you can time the performance like this on the command line: time host snd.dev –  labradort Nov 3 '11 at 18:06
add comment

6 Answers

up vote 17 down vote accepted
+100

Long DNS timeouts are almost always a sign of IPv6 issues.

Do you need IPv6 connectivity to apache ?

If not, I suggest changing

<VirtualHost *:80>

into

<VirtualHost 0.0.0.0:80>

Or disable IPv6 connectivity altogether.

share|improve this answer
3  
+1: ipv6 DNS lookups are a major problem on OSX. For some obscure reason OSX first does ipv6 lookup. If that times out (30 seconds or so) it will continue with v4. OSX doesn't seem to check /etc/hosts first vor v6, it does for v4, but only after v6 has timed out. If you can't disable v6 better make sure that you have a fully working v6 setup including v6 DNS. –  Tonny Nov 1 '11 at 15:37
    
Thanks for the answer. I'm not sure if this is the only issue that is playing a role here, but the time it takes to resolve a local virtual host have dropped most of the time. –  Bart Jacobs Nov 3 '11 at 6:54
    
Thanks, this worked for me. –  pregmatch May 12 '13 at 23:39
add comment

I've run into this just now too.

This will set the IPv6 in Network configuration to Off...

# list all network interfaces to get their names
networksetup -listallnetworkservices
# disable the one you want, in my case it's WiFi
networksetup -setv6off Wi-Fi

But.. unfortunately this didn't solve the DNS resolving issue for me (maybe after system restart). What really helped was to add ipv6 style IPs to /etc/hosts like this:

# my original /etc/hosts ...
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost

127.0.0.1 project.local

# adding this solved resolving:
fe80::1%lo0 project.local

wget http://project.local now shows instantly

Resolving project.local... 127.0.0.1
Connecting to project.local|127.0.0.1|:80... connected.

instead of hanging for 5 seconds on Resolving project.local.

share|improve this answer
    
Your advice was all I needed -- just added the IPv6 entries to my hosts file alongside the standard 127.0.0.1 and the problem was completely solved. –  Kirk Woll Jul 18 '12 at 16:30
    
Yay! This helps in OS X 10.8 (Mountain Lion). After upgrading from 10.6 directly to 10.8 I found my local host lookups too forever... like they were timing out before resolving. This fixed the issue for me. Thanks! –  Lothar_Grimpsenbacher Aug 9 '12 at 22:33
    
I encountered this problem recently and the IPv6 entries in /etc/hosts fixed it perfectly. –  Neil Albrock Oct 20 '12 at 14:08
add comment

Have a look at this blog to see if it helps, specifically highlighting Problem #2:

Apparently, the terminal and some of the BSD Unix tools correctly use /etc/resolv.conf and the correct order of /etc/hosts first and then DNS servers. However, everything else on OS X Lion, including all of your Applications, do it backwards!

share|improve this answer
add comment

On MacOSX Lion .local domain has been "reserved" for Multicast DNS Resolver (bonjour).

This means that looking up any domain ending with .local will result in mDNS lookup (up to 5s) before /etc/hosts.

Fixes:

  1. Change your test domains to some other TLD (i.e. .dev)
  2. Use dscl tool to add an exception.
share|improve this answer
add comment

It works.

I use this solution

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost6
fe80::1%lo0 localhost
share|improve this answer
add comment

I'd try changing:

::1             localhost 
fe80::1%lo0 localhost

to

::1             localhost6 
fe80::1%lo0 localhost6
share|improve this answer
1  
Unfortunately, this does not solve the issue. Can you tell what the logic is behind your suggestion? Thanks for your response though. –  Bart Jacobs Oct 14 '11 at 9:09
    
I recently fought unordinately long times for snmp responses from machines not running IPV6 but having like entries in /etc/hosts. Now the othe thing that comes to mind is a nameserver timing out - bit odd though, because hosts should have precedence over bind. (Configurably so, of course). –  Alien Life Form Oct 14 '11 at 9:13
    
Very odd indeed. On occasions, resolving to a host is instantaneous (as one expects) and on others it can take several seconds. –  Bart Jacobs Oct 14 '11 at 10:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.