DNS は Domain Name System の略で、名前を IP アドレスへ変換する仕組みです。人が覚えるのは名前ですが、実際の通信には IP アドレスが要ります。その橋渡しをしています。
1回の名前解決で、複数の場所に聞いている
「DNS が遅い」「変更が反映されない」の原因を切り分けるには、どこに聞いているかを分けて考える必要があります。
| 順番 | 聞く先 | 持っているもの |
|---|---|---|
| 1 | アプリやブラウザの内部 | 直前の結果を短時間だけ |
| 2 | OS のキャッシュ | 同じく一時的な結果 |
| 3 | 社内やプロバイダのリゾルバ | 多くの利用者ぶんの結果をまとめて |
| 4 | そのドメインの権威サーバー | 本来の答え |
変更したのに反映されないとき、4は新しくなっていて1〜3が古いという状態がほとんどです。世界中が一斉に切り替わることはありません。
どの層を見ているかを指定して確認する
確認のときは、聞く相手を明示すると切り分けが進みます。
# ふだん使っているリゾルバに聞く（キャッシュ込みの答え）
dig example.com A +short
# 特定のリゾルバを指定して聞く
dig @1.1.1.1 example.com A +short
# 権威サーバーに直接聞く（本来の答え）
dig @ns1.example.com example.com A +short
権威サーバーの答えだけが正解です。それが新しくなっていれば設定は完了しており、残りは各所のキャッシュが切れるのを待つ段階だと判断できます。
反映されないという相談の切り分け
権威サーバーが新しい値を返すなら、作業は終わっています。待てば直ります。権威サーバーが古い値を返すなら、設定がまだ反映されていないか、そもそも編集した先が実際に使われている DNS ではありません（ネームサーバーの向き先を確認します）。
疎通と名前解決は別に確認する
障害調査で効くのはこの分離です。ネットワークは生きているのに DNS だけ壊れていると、利用者には「全部つながらない」ように見えます。
# 1. 名前が引けるか
dig example.com +short
# 2. IP に直接つながるか（名前を使わない）
curl -sS -o /dev/null -w "%{http_code}\n" https://203.0.113.10 --resolve example.com:443:203.0.113.10
1が失敗して2が成功するなら、原因は DNS の側です。サーバーを調べても何も出てきません。
社内での位置づけ
社内システムでは、ファイルサーバー、プリンター、認証基盤などを名前で扱うことが多いため、DNS が止まると業務全体が止まったように見えます。実際にはサーバーは動いているのに、たどり着けないだけ、という形です。
だから DNS は、冗長化と変更管理を最初に整えるべき対象になります。1台構成のまま放置されやすい一方で、落ちたときの影響範囲が最も広い部類です。