14

Our company network uses xxx.companyname.local for all the servers on our local network. Whenever I access one of these servers on my Mac, I have a 10 second delay. I have found out that this delay is caused by DNS lookups, because apparently Lion resolves .local domains in the following order:

  1. check /etc/hosts for IPv6 address
  2. check DNS server for an AAAA record (IPv6 address)
  3. check via MDNS (Bonjour) for an AAAA record
  4. check /etc/hosts for an IPv4 address
  5. check DNS server for an A record (IPv4 address)
  6. check MDNS for A record

Now, the problem is, we don't have an IPv6 network. All xxx.companyname.local servers on our network have only IPv4 addresses and the DNS server has only A records. This means that the address is resolved in step 5. The problem with this is that step 3 takes ten seconds before it times out! Every time I connect to our wiki, SVN server, Kerberos server, etc, there is a 10 second delay.

I have managed to trick Lion by adding lines like the following to /etc/hosts

::FFFF:10.99.99.99 xxx.companyname.local

If I do this, Lion thinks there is an IPv6 address for the domain and stops after step 1. However, this workaround totally circumvents all the useful features of DNS. I don't want to manually keep track of the IP addresses of dozens of internal domains! I could as well stop using host names and just type IP addresses!

So: Does anybody have an idea how to change this lookup order? Or disable IPv6 lookup since we don't have an IPv6 network anyway?

5
  • Thanks for the question - I bookmark it as Mac DNS resolution reference ;)
    – Alex
    Dec 22, 2011 at 17:04
  • You'd be far better served trying to determine why your DNS servers are taking 10 seconds to send an empty record set answer for AAAA records when they (according to what you say) don't take anywhere near that long to answer A queries for the very same domain names. You seem to be in classic RFC 4074 territory, where the problem is that the servers are broken. Note, too, that you've hit upon one of the several well-known and long discussed reasons for not using local. for split-horizon DNS service. That's better to fix, as well.
    – JdeBP
    Dec 23, 2011 at 14:33
  • 1
    The DNS servers in step two return an empty AAAA record instantly. The problem is step 3 - the MDNS/Bonjour/Zeroconf query. Lion waits 10 seconds after the broadcast before timing out. After googling a bit I am well aware that using local. is a bad idea, but the IT department told to me that they think using local.companyname. is perfectly fine and I can't really do anything about that. Dec 23, 2011 at 15:24
  • The people in your IT department are vastly underinformed. This has been known to be very much not "perfectly fine" in network administration circles for roughly half a decade. You could … encourage … your IT department people's networking knowledge to be brought into the 21st century. You could … remind … them that their job is not to arrange matters such that the corporate computers don't work properly. ☺
    – JdeBP
    Dec 24, 2011 at 2:17
  • @JdeBP And yet, Apple decided it would be a good idea to use it... You'll note that Microsoft also uses it and recommends it as best practice. So... Who says it's not?
    – Basic
    Jan 8, 2013 at 17:00

2 Answers 2

10

Stop your IT department from abusing local..

As discussed, abusing a domain name that your company does not own, and shouldn't thus be assuming it can create corporate subdomains in, is wrong and is half of the problem here. If the company computers include Macintoshes (or anything else that uses DNSSD for that matter), then most definitely don't assume that local. is yours to freely mess around with in this manner.

Upgrade your Macintosh.

MacOS 10.4 would indeed treat xxx.companyname.local. as you describe. But this has changed in later revisions of the operating system. MacOS 10.5 passes only two-label names to Multicast DNS. Three-label names such as xxx.companyname.local. are not handled by MDNS. MacOS 10.6 takes this further and tries to detect whether the DNS server has been misconfigured to have a local. zone and act accordingly.

At the very minimum you should configure your Macintosh to have an /etc/resolver/companyname.local file with search_order 1 in it that lists the current IP address(es) of your proxy DNS server(s). This will not work well with DHCP-assigned DNS server IP addresses that change, though, as Apple says.

On the gripping hand …

… these are simply progressively more complex bodges to accommodate wrongheadedness. To quote Marc Krochmal of Apple, "there's always going to be some issue" when people abuse local. in the way that your company is doing. It's been known to be wrongheaded since (a quick search tells me) 2002, if not before. Just don't do it.

Further reading

1
  • 3
    None of this information addresses my problems with DNS resolution in Lion (Mac OS X 10.7). Furthermore, /etc/resolver/companyname.local seems to be ignored in Lion. Feb 8, 2012 at 14:28
0

I don't know mac so can't really help, but I came with a clever-ass workaround idea: If you setup somewhere on the internet, "somedomain.com DNAME companyname.local" - it will catch DNAME on step 2. Now I'm not sure what will happen next, will it still fall back to bonjour, or since it's already in the middle of some DNS process maybe it will stick with DNS.

1
  • I can volunteer in creating the DNAME for you if you wish :)
    – Alex
    Dec 22, 2011 at 17:17

You must log in to answer this question.

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