searchドメイン設計のアンチパターン

URLをコピーしました！

Linuxやコンテナ、サーバーアプリの通信トラブルを調査していると、実はsearchドメイン設計ミスが根本原因だった、というケースは少なくありません。

digは通るのにアプリが失敗する
短いホスト名でアクセスすると不安定
環境ごとに名前解決結果が変わる
DNS問い合わせが異常に多い

これらはsearchドメインを「なんとなく」設定していることが原因で発生します。

本記事では、

searchドメインの基本動作
やりがちなアンチパターン
実際に起きる障害
正しい設計・対策

を実務視点で整理します。

searchドメインとは何か（おさらい）

searchドメインは、FQDNでない名前を補完するための仕組みです。

search example.local corp.internal

この場合、

ping app

は内部的に以下を順番に試行します。

app.example.local
app.corp.internal

便利な一方、設計を誤ると予期しない名前解決を引き起こします。

アンチパターン① searchドメインを大量に設定する

よくある設定例

search a.local b.local c.local d.local e.local

何が起きるか

名前解決の試行回数が増加
DNS問い合わせが指数的に増える
タイムアウトによる通信遅延

glibcはsearchドメインを上から順に全て試すため、レスポンスが悪化します。

対策

searchは最小限（1〜2個）に絞る
用途別にFQDN利用を徹底

期待される結果

DNS問い合わせ数削減
通信遅延の解消

アンチパターン② 社内ドメインをsearchに入れる

例

search corp.example.com

何が問題か

短い名前で外部アクセスした場合、

curl google.com

が以下のように解釈されます。

google.com.corp.example.com

結果、

存在しない名前へのDNS問い合わせ
無駄なリトライ
遅延・失敗

対策

外部通信は必ずFQDN指定
searchは内部専用に限定

アンチパターン③ ndots 設定を理解せずに変更

よくある設定

options ndots:5

問題点

ndotsは「ドットの数が何個未満ならsearchを適用するか」を決めます。

ndotsが大きい → searchが頻繁に適用
FQDNでもsearchされる

KubernetesやDockerで特に問題になりやすい設定です。

対策

一般サーバー：ndots:1
Docker/K8s：ndots:0 または明示的FQDN

アンチパターン④ search前提のアプリ設計

典型例

設定ファイルに短縮ホスト名のみ記載
環境依存でsearchに期待

何が起きるか

本番だけ通信不可
コンテナで失敗
VPN接続時に名前解決変更

対策

アプリ設定はFQDNを原則とする
searchは補助用途に限定

アンチパターン⑤ Docker / Kubernetes との組み合わせ

DockerやKubernetesでは、

独自DNS
固定searchドメイン

が自動注入されます。

Kubernetes例

search default.svc.cluster.local svc.cluster.local cluster.local

問題点

短い名前が予期せず内部解決される
外部DNSへの問い合わせが遅延

対策

外部通信は必ずFQDN
アプリ側でDNS仕様を理解

切り分け手順（実務）

① search設定確認

cat /etc/resolv.conf

② 実際の解決順序確認

getent hosts app

③ DNS問い合わせ可視化

tcpdump -i any port 53

想定外のドメインに問い合わせていないか確認します。

正しいsearchドメイン設計の指針

searchは最小限
FQDNを基本とする
ndotsを理解して設定
環境差分（Docker/K8s）を考慮

まとめ

searchドメインは便利だが危険
大量設定・社内ドメイン混在はNG
短縮名依存設計は事故の元
FQDN原則が最も安全

searchドメインのトラブルは、 「設定が悪い」のではなく「設計が悪い」ことがほとんどです。

一度設計を見直すことで、再発を高確率で防げます。