DNSへ手作業でレコードを作っていないのにホスト名で接続できる理由は、1つとは限りません。WindowsのDNS動的更新でAレコードが既に作成された、DHCPサーバーが代理登録した、短い名前へDNSサフィックスが補われた、ローカルキャッシュやhostsファイルが使われた、DNS以外の名前解決が働いた、という可能性があります。まず nslookup や Resolve-DnsName -DnsOnly でDNS応答そのものを確認し、「pingが通る」ことと「DNSに登録済み」を同一視しないのが正しい切り分けです。
最初に「どの名前を、何が解決したか」を分ける
例としてPC名がC01、プライマリDNSサフィックスがcorp.example.comなら、完全修飾名はC01.corp.example.comです。利用者がC01だけを入力しても、DNSクライアントがサフィックスを補って完全修飾名を問い合わせることがあります。短い名前が通ったという結果だけでは、C01という単独レコードがDNSにあるとは判断できません。
hostname
ipconfig /all
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, RegisterThisConnectionsAddress
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName C01.corp.example.com -DnsOnly
Resolve-DnsName C01 -DnsOnly
nslookup C01.corp.example.com上のコマンドは状態照会です。ipconfig /all ではホスト名、プライマリDNSサフィックス、接続固有のDNSサフィックス、利用中のDNSサーバーを確認します。Resolve-DnsNameでは最初にFQDN、次に短い名前を試します。問い合わせ先DNSサーバーと回答された名前、IPアドレス、レコード種別を記録してください。社内ドメイン名とIPアドレスは外部へ公開しません。
理由1：WindowsまたはDHCPがDNSを動的更新した
WindowsのDNSクライアントは、設定が許可されていれば、起動、IPアドレスの追加・変更、DHCPリースの更新、コンピューター名変更などを契機にAレコードやPTRレコードの動的更新を要求します。Active Directory統合DNSゾーンは通常、セキュリティで保護された動的更新を利用し、許可されたコンピューターまたはDHCPサービスがレコードを更新します。このため、管理者がDNSマネージャーで手入力していなくても、DNS上には実際のレコードが存在します。
ドメイン参加はプライマリDNSサフィックスや資格情報、ゾーン構成と関係しますが、「参加した瞬間に必ず登録される」とは限りません。動的更新が無効、クライアントが外部DNSを参照、ゾーンへの更新権限がない、DHCPとの更新分担が不整合、VPN接続で登録しない設定、複数NICの登録制御などにより失敗します。逆に、非ドメイン端末でもゾーンが非セキュア更新を許していれば更新できる構成はあり得ますが、非セキュア更新は推奨されません。
理由2：短いホスト名へサフィックスが追加された
DNSクライアントにはプライマリサフィックス、接続固有サフィックス、サフィックス検索一覧、名前のデボリューションなどがあります。C01を問い合わせた際にC01.corp.example.comへ展開され、そのFQDNのAレコードが回答されれば、利用者には短い名前だけで解決できたように見えます。別ネットワークやVPNで同じ短い名前が違うIPを返す場合は、サフィックス検索順序が異なる可能性があります。
業務スクリプト、証明書、監視設定では、検索サフィックスに依存する短い名前よりFQDNを使う方が判定を安定させられます。ただしFQDNへ変更すると証明書名やアプリ設定へ影響するため、接続先が同一であることを確認してから移行します。
理由3：DNS以外の情報で到達した
Windowsアプリが利用する名前解決経路には、DNSクライアントキャッシュやhostsファイルのほか、ネットワークとポリシーによってLLMNR、mDNS、NetBIOS名解決などが関与する場合があります。ping C01 やエクスプローラーの \\C01 が成功しても、DNSサーバーにAレコードがある証明にはなりません。対してnslookupは指定したDNSサーバーへDNS問い合わせを行うため、結果の意味が異なります。
Get-DnsClientCache | Where-Object Entry -Like 'C01*'
Resolve-DnsName C01 -DnsOnly -NoHostsFile
ping -4 C01最初のコマンドでローカルDNSキャッシュを確認し、2つ目でhostsファイルを使わないDNS問い合わせに限定します。最後のpingは到達性と、アプリに近い名前解決結果を見る補助です。hostsファイルを編集したりキャッシュを消したりする前に、現在値と再現条件を保存します。キャッシュ削除は端末上のほかの名前解決にも影響し、一時的にDNS問い合わせを増やすため、初手にはしません。
結果から原因を判定する
- FQDNのnslookupが正しいIPを返す：手入力の有無にかかわらず、問い合わせたDNSサーバーまたはその参照先にレコードがある
- FQDNは通り、短い名前だけ失敗する：サフィックス検索一覧、接続固有サフィックス、VPNの名前解決ポリシーを確認する
- 短い名前だけ通り、FQDNは失敗する：DNS以外のローカル名前解決、hosts、別サフィックスへの展開を疑う
- nslookupは失敗するがpingは通る：hosts、キャッシュ、LLMNR、mDNS、NetBIOSなどDNS以外の経路を調べる
- 正引きが古いIPを返す：DHCPリース、複数NIC、重複レコード、セキュア更新の所有権、エージングをDNS管理者が確認する
- 端末ごとに結果が違う：利用DNSサーバー、VPN、NRPT、サフィックス検索順序、キャッシュの差を比較する
動的登録を直すときの安全な順序
Microsoftの現行資料は、DHCPクライアントの登録更新では、まずDHCP構成と ipconfig /renew を使う方法を推奨しています。ipconfig /registerdns はクライアントがDHCPサーバーを迂回して直接登録を試み、レコードの所有権が変わって後のDHCP更新を妨げることがあるため、安易に実行しません。DNSゾーンの動的更新設定、DHCPオプション81、サービスアカウント権限、A/PTRの担当をDNS・DHCP管理者が先に確認します。
DNSマネージャーで古いレコードを削除する操作も初手にはしません。同名ホスト、クラスタ、負荷分散、静的割り当てが利用している可能性があります。対象レコードの所有者、タイムスタンプ、TTL、登録元、現在のIPを記録し、バックアップまたは復元可能な変更記録を用意してから、承認された1件だけを修正します。修正後はFQDNのResolve-DnsName、短い名前、実アプリの順に再確認し、別セグメントやVPNからも同じ結果になるかを確認します。
コメント