26

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.

1
  • 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, 2011 at 18:06

7 Answers 7

26
+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.

3
  • 4
    +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, 2011 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. Nov 3, 2011 at 6:54
  • My DNS lookup was taking about 2-5 seconds to resolve, not 30. So, I am not sure what my issue was since that is unlikely to be a timeout. Regardless, it's now instant since making the changes from this answer.
    – Justin
    Jul 12, 2014 at 16:21
22

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.

4
  • 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, 2012 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! Aug 9, 2012 at 22:33
  • I encountered this problem recently and the IPv6 entries in /etc/hosts fixed it perfectly. Oct 20, 2012 at 14:08
  • this it, works now for me on Max OS 10.10.1
    – ezmilhouse
    Mar 31, 2015 at 13:11
12

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.
4
  • Worked for me as well... was driving me crazy that only a few of my dev sites did this... low and behold... all the ones that end in .local! this did not start happening to me until I upgraded to High Sierra... thanks to @artur
    – Mfoo
    Feb 28, 2018 at 20:57
  • 1
    dscl exception strategy is quite nifty. @artur-bodera your link has expired, but they archived their old blog on github github.com/icebourg/itandme-archive/blob/master/posts/2011/08/…
    – lkraav
    Mar 5, 2018 at 18:47
  • Note also that .local is a proposed standard with the IETF: tools.ietf.org/html/rfc6762 It's also really good idea to just register a domain name if you need a "test" domain, since you get full control of how it's configured in DNS. Making up a domain name is very likely to cause weird conflicts with other parts of the domain system (like mDNS in this case.) Aug 18, 2019 at 15:28
  • Thanks!! This worked!
    – Simoyw
    Jun 9, 2021 at 13:57
3

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!

1

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
1

Same bug on Mavericks.

Resolved when I put my local hosts definitions to the beginning of /etc/hosts, like this:

127.0.0.1 localhost project1.dev project2.dev
127.0.0.1 project3.dev project4.dev
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost
0

I'd try changing:

::1             localhost 
fe80::1%lo0 localhost

to

::1             localhost6 
fe80::1%lo0 localhost6
3
  • 1
    Unfortunately, this does not solve the issue. Can you tell what the logic is behind your suggestion? Thanks for your response though. Oct 14, 2011 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). Oct 14, 2011 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. Oct 14, 2011 at 10:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .