知識マップ: Windowsの名前解決の順序 ── hosts・DNSキャッシュ・LLMNR/mDNS・DoH

記事「Windowsの名前解決の順序 ── hosts・DNSキャッシュ・LLMNR/mDNS・DoH」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

Windowsで名前をIPアドレスにする処理はひとつではない。.NETのDns.GetHostAddressesや、宛先へ直接接続するHttpClientはWinsockのgetaddrinfoを呼び(HTTPプロキシ経由では宛先の名前はプロキシ側で解決される)、その下でDNSクライアントサービスがキャッシュ(サービス起動時にhostsファイルを読み込んだもの)→DNSサーバー→単一ラベル名のときだけLLMNR・NetBIOSの優先順位で解決する(既定ではDNSとリンクローカルは並行に問い合わせ、最適化を無効にしたときだけ直列になる)。応答は肯定でも否定でもキャッシュに入り、否定応答は既定5秒のあいだ再試行を失敗させ、ipconfig /displaydnsに「Name does not exist」と出る。ipconfig /flushdns(Clear-DnsClientCache)はそれを捨てる。点を含まない単一ラベル名はサフィックス検索リストで補完されてからDNSに送られ、長いリストは遅延を積み上げる。DNSサーバーが無応答なら開始から1・2・4・8秒の時点で再送して10秒で打ち切り、否定応答が返れば止まり、4番目以降のサーバーには4秒後まで届かない。複数NICでは既定のスマートマルチホーム名前解決が全ネットワークへ並行して問い合わせ、バインド順で採用するため、VPN接続中の結果がPCごとに揺れる。単一ラベル名は既定ではDNSと並行にLLMNRやNetBIOSブロードキャストといった同一サブネット限定の手段にも問い合わせられ、DNSの失敗後に順に試されるのは最適化を無効にしたときだけで(WINSが構成されていればNetBIOSはサブネットを越えられる)、グループポリシー「マルチキャスト名前解決を無効にする」でLLMNRを止めるとDNS未登録の機器の単一ラベル名はLLMNRの経路を失い、NetBTも無効なら引けなくなる。MicrosoftはmDNSに揃えてNetBIOS名前解決とLLMNRを縮退させる方針を示している。Windows 11のDoHはDDRを有効にしていなければ既知のDoHサーバー一覧にあるサーバーにだけ使え、hosts・NRPTと統合されて順序は変えず、「DoHを要求する」はドメイン参加PCに適用しない。Microsoft Edgeは内蔵DNSクライアントとセキュアDNSで列の外にいるため、ブラウザーとアプリの結果は食い違い得る。nslookupはキャッシュ・hosts・NRPTを迂回するので、層ごとの確認はResolve-DnsNameのスイッチと、繋がるPCと繋がらないPCの設定ダンプの差分、Wiresharkのキャプチャで行う。アプリ側は宛先をFQDNで持ち、名前解決の結果と所要時間をログに残し、DNSが問い合わせる候補1つあたり最大10秒(サフィックス検索で候補が複数なら全体はそれを超える)のタイムアウトを見込む。

flowchart LR
    accTitle: Windowsの名前解決の順序の知識マップ
    accDescr: アプリのgetaddrinfoの下でDNSクライアントサービスがキャッシュ(hostsを含む)→DNSサーバー→単一ラベル名だけLLMNR・NetBIOSの優先順位で解決すること(既定ではDNSとリンクローカルは並行)、否定応答もキャッシュされること、サフィックス検索リストと再送タイムアウトが遅延を生むこと、スマートマルチホーム名前解決とLLMNR無効化と単一ラベル名が一部のPCだけの失敗を生むこと、DoHがDDR無効時は既知のサーバー一覧を前提に順序を変えずに輸送路を替えること、ブラウザーの内蔵リゾルバーとセキュアDNSがアプリとの食い違いを生むこと、Resolve-DnsNameと設定ダンプとWiresharkで各層を確かめられること、FQDN指定と名前解決ログが業務アプリの対策になることを示す関係図
    windows_dns_client_service["DNSクライアントサービス"]
    dns_resolver_cache["DNSリゾルバーキャッシュ"]
    single_label_name["単一ラベル名"]
    llmnr["LLMNR"]
    doh_windows_dns_client["Windows DNSクライアントのDoH"]
    dns_gethostaddresses["Dns.GetHostAddresses"]
    getaddrinfo["getaddrinfo"]
    hosts_file["hostsファイル"]
    negative_dns_cache["否定応答のキャッシュ"]
    ipconfig_flushdns["ipconfig /flushdns / Clear-DnsClientCache"]
    get_dnsclientcache["Get-DnsClientCache / ipconfig /displaydns"]
    resolve_dnsname["Resolve-DnsName"]
    nslookup["nslookup"]
    nrpt["名前解決ポリシーテーブル(NRPT)"]
    dns_suffix_search_list["DNSサフィックス検索リスト"]
    name_resolution_delay["名前解決の遅延"]
    dns_client_retry_timeout["DNSクライアントの再送とタイムアウト"]
    smart_multihomed_name_resolution["スマートマルチホーム名前解決"]
    group_policy["グループポリシー"]
    partial_pc_name_resolution_failure["一部のPCだけ名前解決できない"]
    netbios_over_tcpip["NetBIOS over TCP/IP(NetBT)"]
    wins["WINS"]
    turn_off_multicast_name_resolution_policy["「マルチキャスト名前解決を無効にする」ポリシー"]
    mdns["mDNS"]
    fqdn_destination["宛先のFQDN指定"]
    business_app_destination_config["業務アプリの宛先設定"]
    known_doh_server_list["既知のDoHサーバー一覧"]
    require_doh_policy["「DoHを要求する」設定"]
    active_directory["Active Directory(AD DS)"]
    microsoft_edge["Microsoft Edge"]
    edge_built_in_dns_client["Edgeの内蔵DNSクライアント"]
    browser_secure_dns["ブラウザーのセキュアDNS"]
    browser_app_name_resolution_mismatch["ブラウザーとアプリの名前解決結果の食い違い"]
    ipv6_address_preference["IPv6優先のプレフィックスポリシー"]
    disabledcomponents_prefer_ipv4["DisabledComponentsによるIPv4優先"]
    wireshark["Wireshark"]
    name_resolution_config_dump["名前解決設定のダンプと差分比較"]
    name_resolution_logging["名前解決結果のログ"]
    dns_gethostaddresses -->|"利用する"| getaddrinfo
    getaddrinfo -->|"利用する"| windows_dns_client_service
    windows_dns_client_service -->|"利用する"| dns_resolver_cache
    hosts_file -->|"に保存される"| dns_resolver_cache
    negative_dns_cache -->|"に保存される"| dns_resolver_cache
    ipconfig_flushdns -->|"軽減する"| negative_dns_cache
    dns_resolver_cache -->|"で確認できる"| get_dnsclientcache
    dns_resolver_cache -->|"で確認できる"| resolve_dnsname
    hosts_file -->|"で確認できる"| resolve_dnsname
    nslookup -->|"両立しない"| dns_resolver_cache
    nslookup -->|"両立しない"| nrpt
    nrpt -->|"で確認できる"| resolve_dnsname
    single_label_name -->|"利用する"| dns_suffix_search_list
    dns_suffix_search_list -.->|"原因になり得る"| name_resolution_delay
    windows_dns_client_service -->|"利用する"| dns_client_retry_timeout
    dns_client_retry_timeout -.->|"原因になり得る"| name_resolution_delay
    smart_multihomed_name_resolution -->|"で構成できる"| group_policy
    smart_multihomed_name_resolution -.->|"原因になり得る"| partial_pc_name_resolution_failure
    single_label_name -.->|"利用する"| llmnr
    single_label_name -.->|"利用する"| netbios_over_tcpip
    netbios_over_tcpip -.->|"利用する"| wins
    single_label_name -.->|"原因になり得る"| partial_pc_name_resolution_failure
    turn_off_multicast_name_resolution_policy -->|"防止する"| llmnr
    turn_off_multicast_name_resolution_policy -.->|"原因になり得る"| partial_pc_name_resolution_failure
    llmnr -->|"で確認できる"| resolve_dnsname
    mdns -->|"の後継"| llmnr
    mdns -->|"の後継"| netbios_over_tcpip
    fqdn_destination -.->|"防止する"| partial_pc_name_resolution_failure
    fqdn_destination -->|"推奨される対応"| business_app_destination_config
    hosts_file -.->|"用いるのは非推奨"| business_app_destination_config
    doh_windows_dns_client -.->|"前提とする"| known_doh_server_list
    doh_windows_dns_client -->|"利用する"| hosts_file
    doh_windows_dns_client -.->|"利用する"| nrpt
    doh_windows_dns_client -->|"で構成できる"| group_policy
    require_doh_policy -->|"用いるのは非推奨"| active_directory
    require_doh_policy -.->|"原因になり得る"| partial_pc_name_resolution_failure
    microsoft_edge -->|"利用する"| edge_built_in_dns_client
    browser_secure_dns -->|"利用する"| edge_built_in_dns_client
    browser_secure_dns -->|"で構成できる"| group_policy
    browser_secure_dns -.->|"原因になり得る"| browser_app_name_resolution_mismatch
    edge_built_in_dns_client -.->|"原因になり得る"| browser_app_name_resolution_mismatch
    getaddrinfo -->|"利用する"| ipv6_address_preference
    disabledcomponents_prefer_ipv4 -->|"軽減する"| ipv6_address_preference
    windows_dns_client_service -->|"で確認できる"| wireshark
    partial_pc_name_resolution_failure -.->|"で確認できる"| name_resolution_config_dump
    name_resolution_logging -->|"利用する"| dns_gethostaddresses
    name_resolution_logging -->|"推奨される対応"| business_app_destination_config
    business_app_destination_config -.->|"前提とする"| dns_client_retry_timeout

概念間の関係(全48件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• Dns.GetHostAddressesはgetaddrinfoを利用します。Dns.GetHostAddressesは基盤となるOSの名前解決API(Windowsではgetaddrinfo)で実装されており、hostsファイルに記述されたホストはDNSサーバーに問い合わせずそのアドレスが返る。HttpClientもこのDnsクラスの上で動くため、宛先に直接接続する.NETの業務アプリはWindowsの名前解決の順序をそのまま引き継ぐ。HTTPプロキシ経由の要求ではローカルで解決するのはプロキシの名前で、宛先の名前はプロキシ側で解決される。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• getaddrinfoはDNSクライアントサービスを利用します。getaddrinfoはNS_DNS名前空間に対してDNS・ローカルのhostsファイル・その他の仕組みで名前を解決するが、その下で実際に順序を決めて働くのがDNSクライアントサービスで、アプリにはアドレスかエラーしか返らない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• DNSクライアントサービスはDNSリゾルバーキャッシュを利用します。DNSクライアントはキャッシュ→hostsファイル→DNSサーバーの順で名前を解決し、キャッシュで答えが出た名前はDNSサーバーに問い合わせない。応答は肯定でも否定でもキャッシュに保存される。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• hostsファイルはDNSリゾルバーキャッシュに保存されます。hostsファイルの名前とアドレスの対応は、DNSクライアントサービスの起動時にローカルのリゾルバーキャッシュへすべて読み込まれる。ipconfig /displaydnsにはhostsから読み込んだ項目と最近解決したレコードの両方が出る。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• 否定応答のキャッシュはDNSリゾルバーキャッシュに保存されます。DNSサーバーからの否定応答もクライアントのキャッシュに保存され、ipconfig /displaydnsで「Name does not exist」と表示される。既定の保持時間はMaxNegativeCacheTtlの5秒。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典 出典
• ipconfig /flushdns / Clear-DnsClientCacheは否定応答のキャッシュを軽減します。ipconfig /flushdns(Clear-DnsClientCache)は否定キャッシュの項目を含むリゾルバーキャッシュの内容を破棄する。失敗する名前に「Name does not exist」が出ているときの対処として案内されている。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典 出典
• DNSリゾルバーキャッシュはGet-DnsClientCache / ipconfig /displaydnsで確認できます。ipconfig /displaydnsとGet-DnsClientCacheでリゾルバーキャッシュの中身を確認でき、Get-DnsClientCacheなら名前やレコード種別で絞って残りTTLを見られる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• DNSリゾルバーキャッシュはResolve-DnsNameで確認できます。Resolve-DnsName -CacheOnlyはローカルキャッシュだけで解決を試みるので、キャッシュ(hostsを含む)が答えているかを他の層と切り離して確かめられる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• hostsファイルはResolve-DnsNameで確認できます。Resolve-DnsName -NoHostsFileはhostsファイルを飛ばして解決するので、hostsの記述が答えを変えているかを確かめられる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• nslookupはDNSリゾルバーキャッシュと両立しません。nslookupはOSのリゾルバーライブラリを使わず、ローカルのDNSキャッシュとhostsファイルを迂回してDNSサーバーに直接問い合わせる。また設定の先頭のDNSサーバーにしか問い合わせない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典 出典
• nslookupは名前解決ポリシーテーブル(NRPT)と両立しません。nslookupは独自のDNS実装を持ちWindows DNS APIを迂回するため、NRPTの規則が効かない。NRPTの動作確認にはResolve-DnsNameを使う必要がある。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• 名前解決ポリシーテーブル(NRPT)はResolve-DnsNameで確認できます。Windows DNS APIを使うアプリだけがNRPTを利用できるため、NRPTの機能確認には必ずResolve-DnsNameを使うようMicrosoftが求めている。Get-DnsClientNrptPolicy -Effectiveで実効ポリシーも確認できる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• 単一ラベル名はDNSサフィックス検索リストを利用します。点を含まない単一ラベル名は、サフィックス検索リストがあればその順に、無ければプライマリDNSサフィックスと切り詰め、接続固有サフィックスを付けてFQDNにしてからDNSサーバーへ送られる。検索リストが構成されるとそれだけが使われる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典 出典
• DNSサフィックス検索リストは名前解決の遅延の原因になることがあります。長いDNSサフィックス検索リストでは、正しいサフィックスがリストの後ろにあるほど、クライアントがサフィックスを順に付けて問い合わせるぶんだけ遅延が積み上がる。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典
• DNSクライアントサービスはDNSクライアントの再送とタイムアウトを利用します。DNSサーバーが無応答のとき、DNSクライアントは開始から1秒・2秒・4秒・8秒の時点で再送し、10秒で打ち切る。否定応答が返れば処理は止まり、次のサーバーを試すのは前のサーバーが無応答のときだけ。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• DNSクライアントの再送とタイムアウトは名前解決の遅延の原因になることがあります。応答できるDNSサーバーがリストの4番目以降にあると、最初の問い合わせから最低4秒後にしかそのサーバーに届かない。アプリの名前解決タイムアウトがそれより短ければ失敗する。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典
• スマートマルチホーム名前解決はグループポリシーで構成できます。グループポリシー「スマート マルチホーム名前解決を無効にする」を有効にすると、全ネットワークへの並行問い合わせをやめ、DNSを全ネットワークへ、失敗したらLLMNR、それも失敗したらNetBTの直列になる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• スマートマルチホーム名前解決は一部のPCだけ名前解決できないの原因になることがあります。既定では全ネットワークへ並行して問い合わせ、複数の肯定応答があればバインド順で採用する。VPN接続中に社内名を聞くとVPNのDNSと自宅側のDNSがそれぞれ別の肯定応答を返すことがあり、採用される答えがバインド順で決まるため、PCごとに結果が違う。自宅側が否定応答を返した場合はそのアダプターが候補から外れ、VPN側の答えが使われる。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• 単一ラベル名はLLMNRを利用します。単一ラベル名の問い合わせには、単一サブネット上のリンクにマルチキャストで問い合わせるLLMNRも使われる。既定のスマートマルチホーム名前解決ではDNSと並行に問い合わせが出され、非ドメインネットワークではDNSが肯定応答を返してもリンクローカル応答が優先される。「DNSが失敗してからLLMNR」の直列になるのは、最適化をポリシーで無効にしたときだけ。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典
• 単一ラベル名はNetBIOS over TCP/IP(NetBT)を利用します。単一ラベル名の問い合わせには、NetBIOS over TCP/IP(ブロードキャストまたはWINS)も使われる。既定ではDNS・LLMNRと並行に問い合わせが出され、最適化を無効にしたときだけDNSとLLMNRの失敗後に試される。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• NetBIOS over TCP/IP(NetBT)はWINSを利用します。NetBTのノードタイプがP・M・HのときはWINSサーバーに問い合わせる。WINSサーバーが構成されていればH-nodeが既定になる。WINS自体はレガシーで、DNSへの移行が推奨されている。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• 単一ラベル名は一部のPCだけ名前解決できないの原因になることがあります。単一ラベル名はドメイン参加PCではサフィックス補完で解決できても、VPN経由や別サブネットのPC、LLMNRとNetBTを無効化したPCでは補完されず、LLMNRもNetBTのブロードキャストもサブネットを越えないため解決できない(WINSが構成されていればNetBTはユニキャストで越えられることがある)。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• 「マルチキャスト名前解決を無効にする」ポリシーはLLMNRを防ぎます。グループポリシー「マルチキャスト名前解決を無効にする」を有効にすると、DNSクライアントの全アダプターでLLMNRが無効になる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• 「マルチキャスト名前解決を無効にする」ポリシーは一部のPCだけ名前解決できないの原因になることがあります。LLMNRを無効化すると、DNSに登録されていない機器の単一ラベル名はLLMNRの経路で解決できなくなり、NetBTも無効なら引けなくなる。Microsoftの回避策の説明も、そのコンピューターが他のコンピューターから見えなくなることがあると明記している。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• LLMNRはResolve-DnsNameで確認できます。Resolve-DnsName -LlmnrOnlyはLLMNRだけで、-LlmnrNetbiosOnlyはLLMNRかNetBIOSだけで解決を試みるスイッチで、その層で解決できるかを確かめられる。ただしプロトコルを限定して試すだけで普段の解決でどの層が採用されたかは示さないため、スイッチ無しの結果と比べ、食い違えばキャプチャで採用された応答を確かめる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• mDNSはLLMNRの後継に当たります。Microsoftは2022年4月に、mDNSに揃えてNetBIOS名前解決とLLMNRを段階的に縮退させる方針を公表した。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• mDNSはNetBIOS over TCP/IP(NetBT)の後継に当たります。Microsoftは2022年4月に、mDNSに揃えてNetBIOS名前解決とLLMNRを段階的に縮退させる方針を公表した。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• 宛先のFQDN指定は一部のPCだけ名前解決できないを防ぎます。末尾に点があるFQDNはサフィックス補完を経ずにそのままDNSサーバーへ送られる(点を含むが末尾に点が無い名前も既定ではそのまま送られるが、複数ラベル名へのサフィックス付加を許可するポリシーが有効ならサフィックスも試される)ため、設定ファイル・ショートカット・UNCパスの宛先をFQDNにしておけばサフィックスやLLMNR・NetBTといったPCごとに違う仕組みに依存しない(ただし.localで終わる名前は設定済みDNSに加えてmDNSも併用され得る)。SMB2以降がTCP 445で直接接続するのは輸送路の話で、単一ラベル名のUNCホストの解決はLLMNRやNetBTで行われ得るため、.localで終わらないFQDNで書いて初めて名前解決がDNSに固定される。ただし無条件に固定されるのは末尾に点を付けた絶対名で、末尾に点が無いFQDNは複数ラベル名へのサフィックス付加ポリシーが有効ならサフィックスも試され、.local名はFQDNでもmDNSが併用され得る。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典 出典
• 宛先のFQDN指定は業務アプリの宛先設定に対する本記事の推奨です。業務アプリの設定ファイルの既定値・ショートカット・UNCパスはFQDNで持つ。単一ラベル名はサフィックスとリンクローカルプロトコルというPCごとに違う仕組みに依存する。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• hostsファイルを業務アプリの宛先設定に用いることは推奨されません。hostsの編集には管理者権限と手作業が要り、配布と変更履歴を管理できず、hostsを見るかどうかは相手のリゾルバー次第(nslookupは見ない)であるため、業務アプリの運用でhostsに依存する設計は避け、宛先の切り替えは設定ファイルで行う。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• Windows DNSクライアントのDoHは既知のDoHサーバー一覧を前提とします。DDR(Discovery of Designated Resolvers)を有効にしていないWindowsのDNSクライアントがDoHを使えるのは、優先または代替DNSサーバーが既知のDoHサーバー一覧に載っている場合だけ。DDRを有効にしたシステムでは平文で設定したリゾルバーが暗号化エンドポイントを自ら通知できるため、一覧への静的登録は唯一の入口ではなくなる(netsh dnsclient set global ddr=yes|no)。既定はCloudflare・Google・Quad9で、社内DNSはAdd-DnsClientDohServerAddressかnetsh dnsclient add encryptionで登録する。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典 出典
• Windows DNSクライアントのDoHはhostsファイルを利用します。Windows 11の暗号化DNSのサポートは、NRPT・システムのhostsファイル・アダプターやプロファイルごとのリゾルバー指定といった既存のDNS構成と統合される。DoHは輸送路を替えるだけで、hosts・キャッシュの順序は変えない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• Windows DNSクライアントのDoHは名前解決ポリシーテーブル(NRPT)を利用します。NRPTで特定の名前空間に特定のDNSサーバーを割り当て、そのサーバーがDoH対応として既知で、かつ自動格上げ(AutoUpgrade)かアダプターの暗号化設定か全体設定(netsh dnsclient set global doh=auto)のいずれかが有効なら、その名前空間の問い合わせはDoHで行われる。既知なだけで、格上げも暗号化設定も無効で全体設定もautoでなければ平文のまま。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• Windows DNSクライアントのDoHはグループポリシーで構成できます。グループポリシー「DNS over HTTPS (DoH) 名前解決の構成」でDoHを許可・禁止・要求のいずれかにでき、設定アプリの「優先DNS暗号化」やnetsh dnsclient set globalでも切り替えられる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• 「DoHを要求する」設定をActive Directory(AD DS)に用いることは推奨されません。Active Directory Domain ServicesはDNSに強く依存し、Windows Server標準のDNSサーバーサービスがDoHの問い合わせに対応していないため、ドメイン参加PCで「DoHを要求する」を有効にしないようMicrosoftが明記している。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• 「DoHを要求する」設定は一部のPCだけ名前解決できないの原因になることがあります。「DoHを要求する」にすると、設定済みのDNSサーバーがDoH非対応の場合は名前解決そのものが失敗する。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典
• Microsoft EdgeはEdgeの内蔵DNSクライアントを利用します。Microsoft Edgeは既定で、DNSサーバーと通信するソフトウェアスタックとしてOSのDNSクライアントではなく内蔵DNSクライアントを使う。ポリシーBuiltInDnsClientEnabledで制御でき、どのDNSサーバーを使うかには影響しない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• ブラウザーのセキュアDNSはEdgeの内蔵DNSクライアントを利用します。EdgeのDoHの問い合わせは常に内蔵リゾルバーで行われる。BuiltInDnsClientEnabledを無効にしても、DoH使用時は内蔵DNSクライアントが使われる。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• ブラウザーのセキュアDNSはグループポリシーで構成できます。EdgeのセキュアDNSは組織管理下のPCでは既定で無効で、ポリシーDnsOverHttpsMode(off・automatic・secure)とDnsOverHttpsTemplatesで構成する。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• ブラウザーのセキュアDNSはブラウザーとアプリの名前解決結果の食い違いの原因になることがあります。セキュアDNSで別のプロバイダーを選んだEdgeは外部のDoHリゾルバーで社外サイトを引けるが社内DNSしか知らない名前は引けず、逆にOSのDNSが不調でもEdgeだけは開ける。現在のプロバイダーのままなら問い合わせ先は変わらず、暗号化に失敗すれば平文へ戻る。ブラウザーの結果とアプリの結果を同じ経路の証拠として扱ってはいけない。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• Edgeの内蔵DNSクライアントはブラウザーとアプリの名前解決結果の食い違いの原因になることがあります。Edgeの内蔵DNSクライアントは設定済みDNSサーバーに自分で問い合わせ、.NETアプリはgetaddrinfoを通ってOSのDNSクライアントサービスの順序に従うため、同じ名前でも別の答えになり得る。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典
• getaddrinfoはIPv6優先のプレフィックスポリシーを利用します。DNSクライアントはAとAAAAの両方を問い合わせて答えを返し、両方返ったときに使うアドレスを決めるのは答えを受け取ったgetaddrinfoと接続側のスタックで、RFC 3484のプレフィックステーブルに従う。この規則は送信元アドレスや経路の無い使えない宛先を先に外してから候補を並べるもので、使える候補の中では既定でIPv6グローバルユニキャストをIPv4より優先する。AAAAが返っただけで必ずIPv6が試されるわけではない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典 出典
• DisabledComponentsによるIPv4優先はIPv6優先のプレフィックスポリシーを軽減します。MicrosoftはIPv6の無効化を推奨せず、DisabledComponentsに0x20を設定してプレフィックスポリシーでIPv4を優先する方法を案内している。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• DNSクライアントサービスはWiresharkで確認できます。DNSサーバーへの問い合わせが線に出ているかはキャプチャでしか確かめられない。Wiresharkのdns.qry.nameフィルターでどのサーバーへ何が飛び応答があったかが並び、UDP 53を塞がれていれば問い合わせが一切出ない。hostsで答えた名前もキャプチャに現れない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典 出典
• 一部のPCだけ名前解決できないは名前解決設定のダンプと差分比較で確認できます。繋がるPCと繋がらないPCで同じスクリプトを実行し、DNSサーバーの並び・サフィックス検索リスト・接続固有サフィックス・NRPT・DoH・アダプター順・ポリシーのレジストリ値の差分を取ると、答えた層の違いが見える。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典 出典 出典
• 名前解決結果のログはDns.GetHostAddressesを利用します。Dns.GetHostAddressesはgetaddrinfoと同じ結果を返すので、アプリが起動時に主要な宛先について解決したアドレス(IPv4とIPv6)と所要時間を記録しておけば、どのPCでいつから何に解決されていたかを後から追える。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• 名前解決結果のログは業務アプリの宛先設定に対する本記事の推奨です。名前解決に失敗した事実とエラーコードと所要時間が残っていれば、情シスは切り分けをどの手順から始めればよいかが分かる。フォールバックで別の名前や固定IPに黙って切り替えると切り分けが成り立たない。 / 確度: 確立した関係 / 確認日: 2026-09-04 出典
• 業務アプリの宛先設定はDNSクライアントの再送とタイムアウトを前提とします。業務アプリの宛先設定とタイムアウト設計は、DNSクライアントが無応答のサーバーに対して問い合わせる名前1つあたり最大10秒を使い(サフィックス検索リストで候補が複数あれば全体はそれを超える)、2台目には1秒後、3台目には2秒後、4台目以降には4秒後にしか問い合わせが届かないことを前提にする必要がある。接続タイムアウトを2〜3秒に詰めた設計は、期限までに使える応答が届かない構成で名前解決の段階から失敗する。 / 確度: 条件付きの関係 / 確認日: 2026-09-04 出典

主要概念の定義

DNSクライアントサービス

getaddrinfoなどWindows DNS APIの下で名前解決を担うサービス。キャッシュ(hostsを含む)→DNSサーバー→単一ラベル名のときだけLLMNR・NetBIOSの優先順位で解決し(既定ではDNSとリンクローカルは並行に問い合わせる。.local名には設定済みDNSに加えてmDNSの経路も加わる)、肯定・否定どちらの応答もキャッシュする。

DNSリゾルバーキャッシュ

DNSクライアントサービスが保持するローカルのキャッシュ。サービス起動時にhostsファイルの内容が読み込まれ、DNS応答はTTLのあいだ保持される。ipconfig /displaydnsやGet-DnsClientCacheで表示できる。

単一ラベル名

server01のように点を含まない名前。DNSサフィックスで補完されてからDNSに送られ、既定ではDNSと並行に(最適化無効時はDNS失敗後に)LLMNRやNetBIOSブロードキャストといった同一サブネット限定の手段も試される(WINSが構成されていればNetBIOSはサブネットを越えられる)ため、PCの設定とネットワークで結果が変わる。

LLMNR

DNSサーバーもDNSクライアントの構成も要らず、単一サブネット上のリンクにUDP 5355のマルチキャストで問い合わせる二次的な名前解決プロトコル(TCP 5355は切り詰められた応答などのユニキャストのやり取りに使う)。単一ラベル名の問い合わせに、既定ではDNSと並行して使われる。

Windows DNSクライアントのDoH

Windows 11 / Windows Server 2022以降のDNSクライアントが、設定済みDNSサーバーへの問い合わせをHTTPSで送る機能。hosts・NRPT・アダプターごとのリゾルバー指定といった既存の構成と統合され、順序は変えない。

Dns.GetHostAddresses

.NETの名前解決API。基盤となるOSの名前解決API(Windowsではgetaddrinfo)で実装され、hostsファイルに記述されたホストはDNSサーバーに問い合わせずそのアドレスが返る。HttpClientもこの上で動く。

getaddrinfo

Winsockのホスト名からアドレスへの変換関数。NS_DNS名前空間に対してDNS・ローカルのhostsファイル・その他の仕組みで解決し、複数の名前空間プロバイダーの応答を集約して返す。

hostsファイル

名前とIPアドレスの対応を手書きするテキストファイル。Windowsではサービス起動時にDNSリゾルバーキャッシュへ読み込まれ、該当する名前はDNSサーバーに問い合わせずに解決される。

否定応答のキャッシュ

DNSサーバーが「名前が存在しない」と答えた否定応答をクライアントがキャッシュに保持する仕組み。既定の保持時間は5秒(MaxNegativeCacheTtl)で、ipconfig /displaydnsには「Name does not exist」と表示される。

ipconfig /flushdns / Clear-DnsClientCache

DNSクライアントリゾルバーキャッシュの内容を、否定応答の項目も含めてすべて破棄するコマンド。Clear-DnsClientCacheはipconfig /flushdnsと同等。

nslookup

DNSサーバーに直接問い合わせる診断ツール。OSのリゾルバーライブラリを使わず、ローカルのDNSキャッシュ・hostsファイル・NRPTを迂回し、設定の先頭のDNSサーバーにしか問い合わせない。

名前解決ポリシーテーブル(NRPT)

名前空間ごとに使うDNSサーバーやDirectAccess・DNSSECの設定を指定する表。Windows DNS APIを使うアプリだけが利用でき、nslookupなど独自のDNS実装は迂回する。Get-DnsClientNrptPolicy -Effectiveで実効ポリシーを確認する。

DNSサフィックス検索リスト

点を含まない単一ラベル名にDNSサフィックスを付けてFQDNにする仕組み。検索リストがあればその順に、無ければプライマリDNSサフィックスと切り詰め、接続固有サフィックスが使われる。

DNSクライアントの再送とタイムアウト

DNSサーバーが無応答のときにWindowsのDNSクライアントが、問い合わせる名前1つあたり、開始から1秒・2秒・4秒・8秒の時点で再送し10秒で打ち切る規則。否定応答が返れば止まり、次のサーバーを試すのは無応答のときだけで、4番目以降のサーバーには4秒後まで届かない。サフィックス検索リストで候補が複数あれば全体の所要時間はこれを超える。

スマートマルチホーム名前解決

複数のネットワークを持つPCで、DNS・LLMNR・NetBTの問い合わせを全ネットワークへ並行して出し、複数の肯定応答があればバインド順で採用する既定の動作。グループポリシー「スマート マルチホーム名前解決を無効にする」で直列にできる。

NetBIOS over TCP/IP(NetBT)

NetBIOS名をブロードキャスト(UDP 137)またはWINSサーバーで解決するレガシーな仕組み。ノードタイプ(B/P/M/H)で方式が決まり、WINSが未構成ならB-node、構成済みならH-nodeが既定。

「マルチキャスト名前解決を無効にする」ポリシー

DNSクライアントの全アダプターでLLMNRを無効にするグループポリシー。LLMNRの脆弱性の回避策として案内され、副作用としてそのPCが他のPCから見えなくなることがある。

mDNS

UDP 5353のマルチキャストで.local名をローカルネットワーク内で解決するプロトコル。.local名は設定済みのDNSやNRPTでも解決されるため、それを置き換えるのではなく加わる経路である。MicrosoftがNetBIOS名前解決とLLMNRを縮退させて揃える軸として2022年に示した。

宛先のFQDN指定

業務アプリの設定ファイル・ショートカット・UNCパスの宛先を、単一ラベル名ではなく完全修飾ドメイン名で持つこと。末尾に点を付けた絶対名ならサフィックス補完を受けず、点を含むが末尾に点が無い名前も既定ではそのまま送られる(複数ラベル名へのサフィックス付加を許可するポリシーが有効な場合だけ補完される)。単一ラベル名と違い、LLMNR・NetBIOSに依存しない。

「DoHを要求する」設定

グループポリシー「DNS over HTTPS (DoH) 名前解決の構成」でDoHを必須にする設定。DoH非対応のDNSサーバーでは名前解決が失敗し、Windows Server標準のDNSサーバーサービスがDoHに対応していないためドメイン参加PCでは有効にしないようMicrosoftが明記している。

Microsoft Edge

Chromiumベースのマイクロソフト製ブラウザー。本体はActiveXをサポートしない。

ブラウザーのセキュアDNS

Microsoft Edgeなどのブラウザーが、OSとは別にHTTPSでDNSプロバイダーに問い合わせる機能。既定では現在のプロバイダーをDoHに格上げして失敗時は平文へ戻り、別のプロバイダーを選んだときだけ外部のリゾルバーへ行く。組織管理下のPCでは既定で無効で、DnsOverHttpsModeポリシー(off/automatic/secure)で構成する。

Edgeの内蔵DNSクライアント

Microsoft EdgeがOSのDNSクライアントの代わりに既定で使う、DNSサーバーと通信するソフトウェアスタック。どのDNSサーバーを使うかは変えないが、DoHの問い合わせは常にこの内蔵リゾルバーで行われる。

DisabledComponentsによるIPv4優先

Tcpip6\ParametersのDisabledComponentsに0x20を設定してプレフィックスポリシーでIPv4を優先させる方法。MicrosoftはIPv6の無効化ではなくこちらを推奨している。

一部のPCだけ名前解決できない

同じ名前が一部のPCでだけ解決できない、または遅い症状。名前解決のどの層が答えたか(キャッシュ・hosts・サフィックス補完・LLMNR/NetBIOS・NRPT・DoH)がPCごとに違うことで生じる。

名前解決結果のログ

アプリが起動時などに主要な宛先について解決したアドレス(IPv4とIPv6)・所要時間・失敗時のエラーコードをログに残し、フォールバックで黙って切り替えない設計。

業務アプリの宛先設定

業務アプリが接続するサーバーを指定する設定ファイル・ショートカット・UNCパスなどの宛先。書き方によって名前解決のどの層に依存するかが決まる。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このデータセットについて

作成

合同会社小村ソフト

ライセンス

CC BY 4.0 ── 出典(合同会社小村ソフト)とライセンスへのリンクを明示し、改変した場合はその旨を示すことを条件に、再配布・改変を含めて再利用できます

最終確認日

2026-09-04 ── 収録する関係のうち、最後に出典と照合した日

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。