Windows 以外のドメイン メンバーが FQDN ではないコンピューターのホスト名を解決しようとしたときに、Windows ドメイン環境で DNS に何が期待されるかを整理しようとしています。
Windows クライアントは (正当な理由があると思いますが) DHCP 経由で受信したドメイン名をホスト名を解決する際の DNS サフィックスとして使用します。そのため、nslookup server-1 を実行すると、server-1.example.com のレコードが要求されます。Mac から同じことを実行しようとすると、server-1 の検索のみが実行され、失敗します。DHCP から受信したドメイン名は /etc/resolv.conf に として記載されていますdomain example.com
が、 として記載されていないため、search example.com
ドメインを追加せずに検索が失敗します。後者は Linux ベースの携帯電話でも発生します。
どちらのプラットフォームにも理由があるはずなので、その理由についてはあまり気にしていません。私が考えようとしているのは、クライアントに変更を加えずに状況を修正する方法です。 国際アナDHCP/BOOTP オプション 119 は DNS ドメイン検索リストのオプションであると書かれていますが、ほとんどのプラットフォームではオプション 119 はそのままではサポートされていないようです。Windows ではもうサポートされていないようですが、これは大きな問題ではありません。また、*nix プラットフォームでは ISC DHCP4 以上が使用されている場合にのみサポートされます。Mac についてはよくわかりませんが、ここや他の場所ではオプション 119 もサポートされていないと読みました。
何か案は?
答え1
これを読んだ後、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 を確認できません (画面が壊れています)。職場のネットワーク (Windows DHCP) にも自宅のネットワーク (Linux DHCP) にもオプション 119 はありません。実際、どちらもドメイン名をオプション 15 としてのみ渡します。
これを動作させるのに唯一問題だったのは、ホーム ネットワークで 1 語のドメイン名を使用すると、Linux と Mac がそれを認識しなかったことです。変更しなければならなかったのは、ドメイン名の末尾に「.local」を追加することだけです。