I'm trying to sort out what's expected from DNS in a Windows domain environment when a non-Windows, non-domain member tries to resolve a computer's hostname without it being a FQDN.
Windows clients (for what I agree to be good reason) will take their domain name received through DHCP and use it as the DNS suffix when resolving hostnames so that if I do nslookup server-1 it requests the record for server-1.example.com. If I try the same thing from my Mac it only does the lookup for server-1 and fails. The domain name received from DHCP is in /etc/resolv.conf as domain example.com
, but because it's not listed as search example.com
the lookup fails without appending the domain. The latter also happens for my linux-based mobile phone.
I don't really care about the why because I'm sure both platforms have their reasons, what I'm trying to figure out is how to rectify the situation with no modification to the clients. IANA says DHCP/BOOTP option 119 is the option for DNS domain search list, but it appears most platforms don't support option 119 out of the box. Windows doesn't seem to at all anymore, though that isn't a big concern, and *nix platforms only support it when ISC DHCP4 or greater is used. Not sure about Mac but I've read here and elsewhere that it doesn't support option 119 either.
Any ideas?
After reading this I had a look at a Ubuntu 8.10 installation I've just finished on Virtualbox. resolve.conf contains:
As a result, it handles lookups just fine and I can reach any machine with either the host name or the FQDN. My MacBook also handles lookups just fine, both at work and at home, but I'm unable to check its resolve.conf right now (the screen is broken). Neither the work network (Windows DHCP) nor my home network (Linux DHCP) have option 119. In fact both pass the domain name only as option 15.
The only issue I had getting this to work was that Linux and Mac didn't like it when my home network used a single word domain name. Adding ".local" to the end of it is the only change I had to make.