DNS – Properly Set Up Webserver on Local Network

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

• dlove (2002-12-02). The .local domain and DNS issues. macworld.
• Apple Corporation (2010). Mac OS X v10.4, 10.5, 10.6: How to look up ".local" hostnames via both Bonjour and standard DNS.
• Stephen Hoffman (2010). DNS Tips: Mixing unicast and multicast DNS with .local. HoffmanLabs.
• Apple Corporation (2008). Mac OS X 10.3: How to look up ".local" hostnames via both Bonjour and standard DNS.

With standard DNS, you would run a DNS server that is authoritative for the local domain (home. or local., although it's better to avoid the latter – see note below), but also acts as a resolver for all other domains.

dnsmasq can be used for this purpose – it has recursive mode enabled by default and your configuration looks fine; all that's needed is to tell it which nameservers to use for non-local domains. Normally those would be read from system's /etc/resolv.conf file; however, since you want the local domain to work on the DNS server computer too, you will need to create a dedicated copy of resolv.conf which would be used only by dnsmasq, while the original resolv.conf would point to nameserver 127.0.0.1.

# cp /etc/resolv.conf /etc/dnsmasq-resolv.conf
# echo "nameserver 127.0.0.1" > /etc/resolv.conf
# dnsmasq -r /etc/dnsmasq-resolv.conf

Note: These instructions are very basic, and should be adapted to the Linux distro in use. In particular, check the Debian and Ubuntu guides on dnsmasq.

After this, the router needs to be configured to use this computer as the DNS server; all DNS queries by computers in your network would then be handled by dnsmasq.

(Full-featured DNS servers, such as bind9, can perform recursive queries themselves – configuring upstream nameservers becomes entirely optional. This is how your ISP's nameservers work, for example. However, hosting your own domain with bind9 is fairly complicated at first, in comparison with the simple dnsmasq.)

Note: If you have Avahi (aka Bonjour) configured on any computer in the network (which Ubuntu has, by default), it's best if you avoid local. in DNS and choose something like home. instead, as names in the form of name.local are already handled by Avahi.

(Although Avahi normally only responds to current-hostname.local, it is actually possible to publish additional entries such as wiki.local; they will, however, need additional IP addresses to be added due to the way mDNS works. Because of this, using Avahi instead of centralized DNS does not offer any more advantages, so I'm not suggesting it.)