我试图理清当Windows非域成员试图parsing计算机的主机名而不是FQDN时Windows域环境中DNS的预期。
Windows客户端（我同意是很好的理由）将通过DHCP接收他们的域名，并在parsing主机名时将其用作DNS后缀，以便如果我执行nslookup server-1，它会请求server-1.example的logging。 COM。 如果我从我的Mac尝试相同的事情，它只会查找服务器1，并失败。 从DHCP接收到的域名在/etc/resolv.conf中显示为domain example.com ，但由于未将其列为search example.com因此查找失败，但不附加域。 后者也发生在我的基于Linux的手机上。
我并不在意为什么，因为我确定两个平台都有他们的理由，我想弄清楚的是如何纠正这种情况，而不是修改客户端。 IANA表示，DHCP / BOOTP选项119是DNS域search列表的选项，但是大多数平台似乎不支持选项119开箱即用。 Windows似乎根本没有，尽pipe这不是一个大问题，* nix平台只在使用ISC DHCP4或更高版本时支持它。 不知道关于Mac，但我已经读过这里和其他地方，它也不支持选项119。
有任何想法吗？
阅读完本文之后，我看了一下我刚刚在Virtualbox上完成的Ubuntu 8.10安装。 resolve.conf包含：
# Generated by NetworkManager domain ourdomain.local search ourdomain.local nameserver 192.168.0.6 nameserver 192.168.0.7
因此，它处理查找就好了，我可以通过主机名或FQDN到达任何机器。 我的MacBook也可以在工作和家中处理查找，但是我现在无法检查它的resolve.conf（屏幕被破坏）。 工作networking（Windows DHCP）和我的家庭networking（Linux DHCP）都不具有选项119.事实上，只能通过域名作为选项15。
我得到这个工作的唯一问题是，当我的家庭networking使用单个域名时，Linux和Mac不喜欢它。 添加“.local”到最后是我必须做的唯一改变。