Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

An alternative method of handling .local domains Network
There seems to be a great deal of discussion about how to handle .local domains, which Mac OS X uses for Rendezvous. In reviewing the documentation for resolver(5), the /etc/resolv.conf file, and the /etc/resolver directory, I stumbled upon what seems to be the perfect solution.

I'm working on an Active Directory (AD) deployment for a customer that decided to use .local as the TLD for their AD namespace. To fix the problem that using .local created with my Mac OS X laptop, I created a company.local file in /etc/resolver, and populated this file with the nameservers for the company.local AD domain. This allows Mac OS X to use standard DNS to resolve company.local (or subdomain.company.local), while still allowing Rendezvous to operate as expected.

The only drawback I've seen to this approach is that the nameservers in this company.local file don't update via DHCP, so I have to update them manually.
    •    
  • Currently 1.40 / 5
  You rated: 1 / 5 (5 votes cast)
 
[14,395 views]  

An alternative method of handling .local domains | 2 comments | Create New Account
Click here to return to the 'An alternative method of handling .local domains' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
An alternative method of handling .local domains
Authored by: jaskerr on Aug 10, '04 12:36:31AM

Apple makes (essentially) the same suggestion in a Support KB article:

Mac OS X 10.3: How to Look Up ".local" Hostnames via Both Rendezvous and Standard DNS
http://docs.info.apple.com/article.html?artnum=107800

I think the only difference is Apple's recommendation to set the search_order option.



[ Reply to This | # ]
An alternative method of handling .local domains
Authored by: slowe on Aug 10, '04 07:44:31AM

The key difference, as I understand it, between Apple's suggestion (which got me started on this path) and the solution I presented is that this solution doesn't affect Rendezvous in any way. Apple's solution adds standard DNS (as well as Multicast DNS) to the resolution order for .local domains; my solution simply specifies that standard DNS should be used for a specific subdomain of .local, while .local itself is still handled via Multicast DNS.

But you're right--the two solutions are very closely related. This one just seemed to make more sense to me for some reason.



[ Reply to This | # ]