DNSの仕組みを理解していないエンジニアはトラブルの原因を永遠に見つけられない

「サイトが突然見えなくなった」「メールが届かない」「なぜかwwwありとなしで挙動が違う」——こういったトラブルの多くは、DNS設定の問題です。しかしDNSの仕組みを理解していないエンジニアは、原因に辿り着けないまま時間を溶かし続けます。DNSは「インターネットの電話帳」とも呼ばれますが、その仕組みを本当に理解している人は意外と少ないのが現実です。

DNSをたとえで説明すると「住所録の連鎖」のようなものです。あなたが「example.com」にアクセスしようとすると、まずOSのキャッシュを確認し、なければリゾルバ（プロバイダのDNSサーバー）に聞き、リゾルバはルートサーバー→TLDサーバー（.comを管理）→権威DNSサーバーの順に問い合わせて最終的にIPアドレスを返します。この全体の流れを「名前解決」と呼びます。

新人エンジニアC：「Aレコードを変えたのに、まだ古いIPに繋がるんですけど」
ベテランD：「TTLの値はいくつだった？」
C：「TTL？なんですか、それ」
D：「Time To Live。DNSレコードをキャッシュしておく時間のことだよ。TTLが86400（24時間）なら、変更しても24時間は古い情報がキャッシュされたまま世界中に残る。変更前にTTLを短くするのが定石だよ」

実際にDNSの動きをコマンドで確認してみましょう。

# Aレコードの確認
dig example.com A

# 権威DNSサーバーへ直接問い合わせ（キャッシュを使わない）
dig example.com A @8.8.8.8

# TTLの確認（+nocmd +noall +answer で見やすく）
dig example.com A +nocmd +noall +answer

# MXレコード（メール設定）の確認
dig example.com MX

# NSレコード（ネームサーバー）の確認
dig example.com NS

# TXTレコード（SPF/DKIM等）の確認
dig example.com TXT

よく使うDNSレコードの種類を整理しておきましょう。AレコードはドメインをIPv4アドレスに紐付けるもの、AAAAはIPv6、CNAMEは別のドメイン名へのエイリアス、MXはメール受信サーバーの指定、TXTはSPF・DKIM・サイト認証などテキスト情報の格納、NSはそのドメインの権威DNSサーバーの指定です。

「DNSの変更が反映されない」というトラブルの9割はTTLとキャッシュの問題です。変更作業の前日にTTLを300（5分）に下げておき、作業後に元の値に戻す——この手順を習慣にするだけで、DNSトラブルの大半は防げます。DNSを理解することは、インターネット上でものを動かすすべての基礎です。今日、digコマンドを打つところから始めましょう。