単一の仮想ネットワークがあり、Azure には単一のクラウド サーバーがあります。この仮想ネットワークには、Windows マシンや Linux マシンなど、複数のサーバー ノードがあります。Windows マシンの 1 つは、仮想ネットワーク内の名前解決を目的として、ローカル DNS サーバーをホストしています。すべてのノードは DNS オプションを使用して作成されたため、ローカル DNS はノードの DNS として登録されます。また、仮想ネットワーク設定が更新され、この DNS サーバー (172.16.0.4) が VN の DNS として含まれるようになりました。
私の Windows マシンは正常に動作しています。新しいプロビジョニングまたは再起動時に、DNS が自動的に更新され、そのマシンの新しい IP (存在する場合) が反映されます。
ただし、Linux マシンはこのローカル DNS にはまったく登録されていません。Linux ノードはローカル DNS (172.16.0.4) を使用して Windows ノードの IP を解決できますが、名前解決を介して他の Linux ノードに到達することはできません。
resolvconf/resolvconf.d/tail ファイルを更新し、「search」エントリを追加して再起動してみました。また、Linux サーバーのホスト名ファイルに FQDN を指定してみました。resolv.conf にはまだ「search reddog.microsoft.com」という文字列が含まれていることに気付きました。これは、VN 内で新しいローカル DNS サーバーが使用可能であるにもかかわらず、使用されている DNS サフィックスがまだ古いものであることを示しています。resolv.conf は次のようになります。
nameserver 172.16.0.4
search reddog.microsoft.com
私の理解では、この問題の根本的な原因は、Azure DHCP サーバーが、この VN に出現する新しいノードまたは再起動されたノードのレコードを更新するために、このローカル DNS (VN レベルの DNS として正式に登録されている) に DDNS 要求を送信する必要があることです。しかし、Azure DHCP はこれらの DDNS 要求を DNS に送信していないようです。何が足りないのでしょうか?
答え1
私の最初の考えは、これは DNS サーバーが Linux サーバーからの登録を受け入れることの問題であり、そこにリダイレクトされることの問題ではないということです。確認すべきことの 1 つは、DNS ゾーンが安全でない更新を受け入れるように設定されているかどうかです。これは、Linux サーバーが DNS を更新するために認証できないため必要です。
答え2
次の行を追加することで、DHCP クライアントの設定を変更できます。
supersede domain-name "your.domainname.com";
supersede domain-search "your.domainname.com";
supersede search "your.domainname.com";
/etc/dhcp/dhclient.conf通常、DHCP 構成はファイル内に見つかります。正しい構成を見つけるには、dhclientファイル内を検索してください。/etc/
答え3
言うまでもなく、/etc/resolv.conf の内容は、サーバーが再起動されるたびに Azure のデフォルトにリセットされます。したがって、変更したとしても、次回再起動すると、検索ドメインは reddog.microsoft.com に戻り、デフォルトの Azure ネームサーバーが設定されます。