Active Directory統合DNSでSRVレコード（LDAPなど）をnslookupすると「Truncated, retrying in TCP mode.」「communications error: end of file」「Format error(FORMERR)」で失敗し、しかも特定のDC参照時だけ発生する――この状況はDNS/ADの設定不備よりも、経路上のファイアウォールやDNSインスペクションが応答を壊しているケースが多いです。切り分け手順と実務的な対処をまとめます。
現象の特徴（まずは「何が起きているか」を言語化する）
本記事で扱うのは、AD（Active Directory）統合DNS環境でSRVレコードを引いたときに、クライアント側のnslookupだけが失敗するタイプのトラブルです。代表的には次のようなメッセージが出ます。
;; Truncated, retrying in TCP mode.;; communications error: end of file*** ... can't find ... : Format error（応答コードがFORMERR）
ポイントは、次の条件がそろうことです。
- データセンター（サイト）が2つあり、片方のDC/DNSを参照したときだけ失敗する
- TCP/UDP 53は「開いている」前提（疎通テストは通る）
- 問題のDC自身でself-lookupすると正常に応答する（DNSサーバー単体の故障に見えにくい）
この組み合わせは、DNSサーバーが悪いというより「経路上でDNS応答が壊れている」可能性が高いサインです。とはいえ、最初にDNS/AD側の基本を固めてからネットワークに進むと、手戻りが減ります。
まず押さえる：ADでよく見るSRVレコード（LDAP/GC/Kerberos）
SRVレコードは「どのサーバーに、どのサービス（ポート）で接続すべきか」を示します。Active Directoryでは、ドメイン参加端末やサーバーがDC探索（DC Locator）を行う際に、SRVを多用します。代表例を整理しておくと、照会名の誤りで迷子になりません。
| 用途 | よく使われる照会名（例） | 意味 |
|---|---|---|
| DC探索（LDAP） | _ldap._tcp.dc._msdcs.contoso.com | ドメインコントローラー（DC）のLDAPサービス一覧 |
| Kerberos | _kerberos._tcp.contoso.com | Kerberosサービス（認証）の参照先 |
| グローバルカタログ（GC） | _gc._tcp.contoso.com | GCサーバー（ポート3268/3269）の参照先 |
| サイト考慮（例：サイト名がTokyo） | _ldap._tcp.Tokyo._sites.dc._msdcs.contoso.com | 特定サイト内のDCに寄せるための照会 |
「SRVは引けるが、意図しないDCが返る」場合は、ADサイトとサブネットの関連付けミスでサイト判定が崩れ、結果としてSRV応答の中身や件数が増える（＝応答肥大化）ことがあります。単なるDNSの話に見えて、AD設計が絡む典型例です。
なぜ「Truncated → TCPに切替 → end of file / FORMERR」になりやすいのか
SRVレコードの応答が大きいと、DNSはまずUDPで返しきれず、応答に「切り詰め（TCフラグ）」が立つことがあります。するとnslookupはTruncated, retrying in TCP mode.のとおり、同じ問い合わせをTCP 53でやり直します。
ここでTCPのDNS応答が経路上の機器で遮断・改変・欠損すると、クライアントは「途中までしか読めない」状態になり、end of fileやFormat error (FORMERR)が出ます。つまり、
- 最初のUDPは大きくて切り詰められる（または途中機器がUDPの断片化/EDNS0に弱い）
- 次のTCPが途中で切れる／内容が壊れる
という二段構えで失敗していることが多いです。特にADのSRVは、ドメインコントローラー数やサイト数が多いほど応答が大きくなりやすく、さらに「Additional section」にAレコード（ホスト名→IP）が多数付くとサイズが増えます。
最初にやるべき：DNS/AD側の「基本確認」（ここで躓くと全てがブレる）
SRVレコードが“正しい場所”に存在するか
ADが自動生成するSRVレコードは、代表的に_msdcs配下などに作成されます。LDAPのDC探索でよく使うのは次です。
nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com 192.0.2.10ここで重要なのは「SRVが存在するか」だけでなく、期待するDC名が返るか、返る件数が極端に多すぎないか、Additional sectionが増えていないかです。
PowerShellで同じ問い合わせを再現する（nslookup依存を減らす）
Windows環境なら、Resolve-DnsNameでもSRVの検証ができます。nslookupが疑わしい場合の比較にも使えます。
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.com -Server 192.0.2.10 -DnsOnly同じサーバーに対して、nslookupだけ失敗し、Resolve-DnsNameは成功する／その逆、という結果も切り分け材料になります（内部的な実装差で、通り方が変わることがあります）。
DNSサーバー側の健全性チェック（dcdiag）
DCの健全性はまずdcdiagで確認します。DNS関連のテストも含めて出すのが基本です。
dcdiag /test:dns /v /s:DC01
dcdiag /test:dns /v /s:DC02ここが正常で、かつSRVが正しく存在するなら、DNS/ADの基礎部分はクリアしている可能性が高く、次の「経路」へ進む価値が上がります。
AD統合DNSの“レプリケーション”視点も確認する
「片方のDCだけおかしい」と聞くとDNSゾーンの複製不整合を疑いたくなります。AD統合DNSはADのレプリケーションに乗って複製されるため、念のため次も確認します。
repadmin /replsummary
repadmin /showrepl DC01
repadmin /showrepl DC02レプリケーションに明確な異常がある場合は、ネットワーク以前にAD側の整合性が崩れている可能性があるため、先に潰しておくとよいです。
DNSサーバーでレコードを直接確認する（GUIが使えないときの手札）
「実際にDC側にSRVが存在するか」「期待するゾーンにいるか」をコマンドで裏取りすると、会話が速くなります。
dnscmd DC01 /enumrecords _msdcs.contoso.com @ /type SRV
dnscmd DC02 /enumrecords _msdcs.contoso.com @ /type SRVGUI（DNS Manager）で見たつもりでも、参照しているサーバーやゾーンが違った、という事故は現場で起きがちです。コマンドでサーバー名を明示して確認すると取り違えを防げます。
診断の要点を表で整理（エラー表示 → 意味 → 疑う場所）
| 表示・症状 | 何が起きているか（推定） | よくある原因（優先度順） |
|---|---|---|
Truncated, retrying in TCP mode. | UDP応答がサイズ超過で「切り詰め（TC）」になり、TCPで再試行している | SRV応答が大きい／途中機器がEDNS0・断片化に弱い／UDPサイズ制限が厳しい |
communications error: end of file | TCP接続は開始できたが、応答を最後まで受け取れず途中で切断された | FWがRST/タイムアウト／DNSインスペクションの不具合／ロードバランサやNATの挙動 |
Format error（FORMERR） | 受信したDNSメッセージが壊れていて解析できない（欠損・改変・途中切断など） | 途中機器がDNSパケットを改変／TCPデータ欠損／分割再構成失敗（MTU/断片化） |
| 特定DC指定時のみ発生 | 名前解決の経路・通り道がDCごとに異なる | データセンター間FWポリシー差／経路上の装置差／SNAT/ロードバランサの片寄り |
DNS/ADが正常なら、ネットワーク（FW/経路/装置機能）を疑うべき理由
この系の障害でよくある落とし穴は、「TCP/UDP 53が開いている＝DNSが正しく通る」ではない点です。実務では次のような“別条件”で壊れます。
DNS over TCPは「セッション維持」「サイズ」「インスペクション」の影響を受ける
- ステートフルFWのタイムアウトが短く、応答が返る前に切れる
- DNSインスペクション（DNS ALG / DNS Proxy / DPI）が、応答の圧縮・分割やEDNS0を正しく扱えず破損させる
- ロードバランサやNATがセッションを途中で貼り替える（片方向だけ通る、など）
SRVの応答が大きいほどTCPに切り替わる頻度が上がるため、「普段は平気だがSRVだけ失敗」「特定のサイト/経路だけ失敗」が起きやすくなります。
MTU/断片化（フラグメント）問題は“SRVだけ”で顕在化しやすい
UDPのDNS応答が大きいと、途中でIP断片化されます。経路上の装置が断片化パケットを落とす、または再構成に失敗すると、クライアントは不完全な応答を受け取ります。結果として、
- UDP応答が壊れる → TCでTCPへ
- TCPも同様に途中で切れる/欠損する → end of file / FORMERR
という見え方になることがあります。MTUが関係していそうなら、後述のping -f -lでサイズを変えて検証すると仮説が立てやすいです。
「DNSインスペクション／DNSセキュリティ機能」の存在を前提にする
近年のセキュリティ機器は、DNSトンネリング対策やマルウェア対策のためにDNSを中継・解析・改変する機能を持つことがあります。設定名は機器やベンダーによって異なりますが、概念としては以下です。
- DNS Proxy / DNS ALG
- DNS Inspection / DNS Filter
- Security Profile（DNSを解析してブロック/書き換え）
AD内のDNS（特にDC間・サイト間の通信）は、可能であればこれらの機能の“対象外（バイパス）”にするのが定石です。内部DNSを「インターネット向けDNS」と同じ扱いにすると、思わぬ副作用が出ます。
現場でそのまま使える切り分け手順（DNS→ネットワークの順に）
以下は、手戻りを減らすための実務フローです。まず「再現条件を固定し、正常系と異常系を同じ手順で並べる」ことが重要です。
| ステップ | 目的 | コマンド例 | 見るポイント |
|---|---|---|---|
| 1 | 問い合わせ先DNS/DCを固定して再現 | nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com 192.0.2.10 nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com 198.51.100.10 | 片方だけ失敗することを確認（ログ採取の前提を固める） |
| 2 | TCP強制で挙動を見る（UDP由来か切り分け） | nslookup -vc -type=SRV _ldap._tcp.dc._msdcs.contoso.com 192.0.2.10 | TCP強制でも失敗するなら「TCP経路」問題の可能性が上がる |
| 3 | PowerShellで比較（実装差での見え方を確認） | Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.com -Server 192.0.2.10 -DnsOnly | nslookupだけ壊れる/両方壊れるで次の手当が変わる |
| 4 | TCP/UDP 53の疎通を“アプリ目線”で確認 | Test-NetConnection 192.0.2.10 -Port 53 Test-NetConnection 192.0.2.10 -Port 53 -InformationLevel Detailed | 疎通OKでも「大きい応答が通る」保証にはならない点に注意 |
| 5 | MTU仮説の簡易テスト | ping 192.0.2.10 -f -l 1472 ping 192.0.2.10 -f -l 1400 | フラグメント禁止で通る最大サイズが異常に小さいと疑いが濃くなる |
| 6 | クライアント/サーバーでパケットキャプチャし比較 | （後述の手順参照） | TCPのRST/FIN、DNS応答の欠損、途中機器での改変の有無 |
nslookupの“デバッグモード”で見える情報を増やす
nslookupは対話モードにしてdebugを有効にすると、問い合わせの詳細が見えるようになります。再現性のある証拠として、ネットワークチームに渡すときにも役立ちます。
nslookup
> server 192.0.2.10
> set type=SRV
> set debug
> set d2
> _ldap._tcp.dc._msdcs.contoso.comここで「UDPでTCになった」「TCPに切り替えた」「応答がどこまで来ているか」などを読み取ります。ログが取れたら、正常DCと異常DCの出力を並べて差分を見るのがコツです。
DC Locatorの観点でも確認する（SRVの“利用者”側から見る）
SRVを引けるかどうかは重要ですが、最終的に困るのは「端末/サーバーがDCを見つけられない」ことです。DC Locatorの確認として、次のようなコマンドも併用すると、障害の影響範囲が見えます。
nltest /dsgetdc:contoso.com
nltest /dclist:contoso.comここでエラーが出たり、意図しないサイトのDCばかり返る場合は、DNSだけでなくADサイト設計（サブネット定義、サイトリンク、クライアントのDNS設定）が影響している可能性があります。
パケットキャプチャで“決着”を付ける（どこで壊れているかを特定する）
推測だけでFW設定をいじると、時間だけが溶けます。最短で原因に近づくのは、正常DCと異常DCでキャプチャを取り、差分を見せることです。少なくとも「クライアント側」と「DNSサーバー側（DC側）」の2点で取れると強いです。
クライアント側で見るべきポイント
- UDP応答にTCフラグが立っているか（切り詰めの発生）
- TCPの3ウェイハンドシェイク（SYN/SYN-ACK/ACK）が成立しているか
- DNS応答（TCP上）が途中で途切れていないか、RSTが出ていないか
- 再送（Retransmission）が多発していないか
DNSサーバー（DC）側で見るべきポイント
- DCがTCP 53で応答を最後まで送っているか
- DCが送った直後にRSTを受けていないか
- 「送ったはずのセグメントがクライアントに届いていない」兆候がないか
Wiresharkでの表示フィルタ例（迷わないための最低限）
Wiresharkを使える場合は、最初はフィルタを絞ると読みやすいです。
dns
tcp.port == 53
ip.addr == 192.0.2.10正常系と異常系で「TCP接続は最後まで維持されているか」「DNS応答が途中で途切れていないか」「RSTの発信元はどちらか」を見るだけでも、次の一手が決まりやすくなります。
Windowsでの採取例（手元でできる範囲）
環境によりますが、サーバーにWiresharkを入れられない場合でも、OS標準のトレース機能で最低限の証拠を集められます。
- netsh trace（ETL形式で取得）
- pktmon（対応OSならフィルタしやすい）
netsh trace start capture=yes tracefile=C:\\Temp\\dns_trace.etl maxsize=512
（再現操作：nslookup実行）
netsh trace stop取得したトレースを解析できる体制があるなら、DNS応答が「DCから出ているのにクライアントに届いていない」など、経路上の問題を示す材料になります。
ネットワークチームに依頼するときの“具体的な確認項目”（丸投げしない）
「53番が開いているか」だけでは不十分なので、依頼時はチェック観点を具体化します。次のように伝えると話が早いです。
- TCP/UDP 53が通ることに加えて、大きいDNS応答（SRVで件数が多い、Additionalが多い）を阻害していないか
- 経路上にDNSインスペクション（DNS ALG / DNS Proxy / DPI）が有効な機器がないか、または内部DNS通信が例外化されているか
- TCPセッションが途中で切れていないか（タイムアウト、ポリシー、IDS/IPSの誤検知）
- MTUやMSSクランプ、断片化ポリシーの差（データセンター間で設定差がないか）
- ロードバランサ／NATが介在していないか（DNSだけ特別扱いされていないか）
このとき、正常DCと異常DCのキャプチャ差分、nslookup debugの差分を添付すると「ネットワーク起因」の説明が通りやすくなります。
暫定回避策（切り分けを進めながら業務影響を下げる）
根本解決は「DNS応答が壊されない経路にする」ことですが、調査に時間がかかる場合は、影響を抑えるために次を検討します。
参照DNS/DCを正常側に寄せる（ただし設計に沿って）
- クライアントのDNS設定（DHCPオプション006など）で、同一サイト内のDCを優先させる
- ADサイトとサブネットの関連付けを見直し、クライアントが適切なサイトのDCを参照するようにする
「常に片方のデータセンターのDNSへ行ってしまう」状態だと、障害が顕在化しやすくなります。まず設計どおりに“近いDCを引く”状態を作るだけでも、体感の障害は減ることがあります。
DNSインスペクションの無効化・バイパス（限定的に）
社内ポリシーにもよりますが、AD内のDNS通信までフルインスペクションする必然性が薄いケースは多いです。内部向け通信を例外化できるなら、障害回避として効果が出やすいポイントです。
応答を小さくする発想（最後の手段）
根治ではありませんが、SRV応答の肥大化が原因の場合、応答サイズを下げると症状が出なくなることがあります。ただしADの仕様や要件に直結するため、実施は慎重に判断してください。
再発防止のための運用チェック（“一度直って終わり”にしない）
- データセンター間のFWポリシー差分を定期的に棚卸しする（特にDNS関連）
- DNSインスペクションの適用範囲を明確化し、内部AD通信の扱いをドキュメント化する
- DC追加・削除のたびにSRV応答サイズが増えうるため、増設時にSRVの応答が適切か確認する
dcdiag /test:dnsやADレプリケーションの定期確認を運用に組み込む
よくある質問（現場で詰まりやすいポイント）
TCP/UDP 53は通るのに、なぜnslookupだけ失敗しますか？
ポート疎通は「コネクションが作れる」ことの確認に留まることが多く、大きいDNS応答が壊れずに往復できるかまでは担保しません。SRVは応答が大きくなりやすく、UDP→TCP切替が発生しやすい分、経路の癖が表に出ます。
問題のDC上ではself-lookupが成功します。DC側の不具合ではないのですか？
self-lookupは「同一ホスト内」または「同一セグメント内」に近い経路で完結しがちです。データセンター間通信のように途中装置が増えると、インスペクションやMTU差分が影響して、外部からの問い合わせだけ壊れることがあります。
FORMERRが出るなら、DNSサーバーが壊れた応答を返している可能性は？
可能性はゼロではありません。ただし「特定経路だけ」「self-lookupは正常」という条件がそろう場合、サーバー実装の不具合よりも、途中で応答が欠損・改変されてクライアントが解析できなくなっているケースが実務上は多いです。キャプチャ差分で“どこまで届いているか”を確認すると結論が早くなります。
まとめ：結論は「DNS/ADの基本確認 → 問題なければ経路（FW/インスペクション/MTU）を疑う」
SRVレコードのnslookupが、特定のDC参照時だけTruncated→end of fileやFORMERRで落ちる場合、まずSRVの存在・dcdiag・レプリケーションなどの基本を押さえ、それでも問題が見えないならネットワーク経路上でDNS応答が壊れていることを前提に切り分けるのが最短です。正常系と異常系を同じ手順・同じ条件で並べ、パケットキャプチャで“どこで欠けるか”を突き止めると、対処（DNSインスペクションの例外化、MTU/MSS調整、FWポリシー修正）に一直線で進めます。
コメント