💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — なぜ今あらためて DNS なのか

最近、GeekNews や Hacker News で DNS が再び議論の中心になりました。ある CDN 事業者が DNS ホスティングを事実上無料で開放したことで、「名前解決というインターネット最古のインフラがついに無料になった」という議論が活発になったのです。無料化そのものよりも興味深いのは、これをきっかけに多くの開発者が「ところで DNS は実際どう動いているのか」という根本的な問いを再び投げかけ始めたことです。

DNS はインターネットで最も当たり前とされている技術です。ブラウザにドメインを入力すると勝手に IP アドレスに変わり、私たちはその過程をほとんど意識しません。しかしその「勝手に」の内部には、再帰問い合わせ、権威サーバへの委任、キャッシュ階層、TTL の失効、Anycast ルーティング、そしてセキュリティ拡張まで、驚くほど精緻な分散システムが隠れています。

本記事では、ひとつのドメインが IP アドレスに解決されるまでの全過程をたどりながら、レコードの種類、Anycast、GeoDNS、DNSSEC、DoH/DoT まで深く見ていきます。そして無料 DNS が普及した 2026 年に実際に直面する運用上の落とし穴も整理します。

DNS をきちんと理解すれば、単に「ドメインが開かない」という漠然とした不安から抜け出し、問題の正確な位置を突き止められるようになります。キャッシュの問題か、委任の問題か、転送層の問題かを区別する力は、インフラを扱うすべての人にとって頼もしい武器になります。

DNS の基本構造 — 階層的な委任システム

DNS は世界中に分散した巨大なツリー構造のデータベースです。最上位にはルート(root)があり、その下に最上位ドメイン(TLD)、さらにその下に私たちが登録するドメインが位置します。

. (ルート)

+------------+------------+

| | |

com org kr

| | |

example wikipedia co.kr

www.example.com

この階層構造の核心は「委任(delegation)」です。ルートサーバはすべてのドメインを知っているわけではありません。ただ「com は向こうのサーバたちに聞け」と案内するだけです。com を管理するサーバも example.com の具体的なレコードを直接は知らず、「example.com はこの権威サーバに聞け」と委任します。

この委任構造のおかげで、DNS は中央集権なしに世界規模で拡張します。誰も全体を知る必要はなく、それぞれが自分の領域だけを担当すればよいのです。

この設計は 1980 年代初頭に登場しました。それ以前は、すべてのコンピュータの名前とアドレスを hosts.txt という単一ファイルにまとめ、各機関がダウンロードしていました。インターネットが大きくなるにつれ、この方式はすぐ限界に突き当たりました。ファイルは肥大化し、更新は遅く、単一ファイルを管理する場所に負荷が集中しました。DNS はまさにこの「中央集権ファイル」の問題を「分散された委任ツリー」で置き換えるために生まれました。40 年経った今もこの基本設計がほぼそのまま動いているという事実は、良い分散システム設計の威力をよく示しています。

再帰サーバと権威サーバ

DNS には役割の異なる二種類のサーバがあります。

- **権威サーバ(Authoritative Server)**: 特定ドメインの実際のレコードを保持するサーバです。example.com の A レコードが何かについての「最終的な答え」を持つ主体です。

- **再帰サーバ(Recursive Resolver)**: クライアントの代わりにルートから権威サーバまで順に問い合わせ、答えを見つけてくれるサーバです。通信事業者の DNS や 8.8.8.8、1.1.1.1 のような公開リゾルバがこれにあたります。

私たちがドメインを入力すると、実際には再帰サーバに「この名前の答えを探して」と頼んでいるのであり、再帰サーバがすべての手間を代行します。

この二つの区別は実務で非常に重要です。問題を診断するとき、「再帰サーバが誤ってキャッシュしたのか」、それとも「権威サーバのレコード自体が誤っているのか」を見分けることが第一歩だからです。権威サーバに直接問い合わせればキャッシュを飛ばして本当の答えを見られ、いつものように再帰サーバに問い合わせればキャッシュされた答えを見ます。この二つを比較するだけで、多くの DNS 問題の原因が明らかになります。

名前解決の全過程 — ひとつの問い合わせをたどる

www.example.com を初めて訪れるとき、再帰サーバの立場で何が起きるかを段階的にたどってみましょう。

クライアント -> 再帰: www.example.com の A レコードをくれ

再帰 -> ルート: www.example.com を知ってる?

ルート -> 再帰: com はあの TLD サーバに聞け(委任)

再帰 -> TLD: www.example.com を知ってる?

TLD -> 再帰: example.com はこの権威サーバに聞け(委任)

再帰 -> 権威: www.example.com を知ってる?

権威 -> 再帰: A レコード = 93.184.216.34

再帰 -> クライアント: 93.184.216.34(そしてキャッシュに保存)

最初は何度も往復しますが、再帰サーバは一度受け取った答えをキャッシュに保存します。そのため同じドメインへの以降の問い合わせはほぼ即座に応答されます。このキャッシュ階層が DNS 全体の負荷を劇的に下げる鍵です。

興味深い点は、再帰サーバが最終的な答えだけをキャッシュするのではないことです。委任情報(どの TLD サーバ、どの権威サーバが担当するか)も一緒にキャッシュします。そのため example.com を一度照会した後は、同じドメインの別のサブドメイン(api.example.com など)を照会するとき、ルートと TLD を再び経由せず直接権威サーバへ行けます。この中間キャッシュのおかげで、二度目の問い合わせからは最初よりもはるかに速くなります。

キャッシュと TTL — 速さと正確さのバランス

各レコードには TTL(Time To Live)という値が付きます。これは「この答えを何秒間キャッシュしてよい」という有効期間です。

example.com. 300 IN A 93.184.216.34

^^^

TTL = 300 秒(5 分)キャッシュ可能

TTL はトレードオフの産物です。

- **長い TTL**: キャッシュヒット率が高く、速く、権威サーバの負荷が少ない。しかしレコードを変えたとき変更が伝わるのに時間がかかります。

- **短い TTL**: 変更が速く反映されますが、キャッシュ効果が減って問い合わせが頻繁になり、応答が遅くなることがあります。

移行を控えて TTL をあらかじめ下げておくのは DNS 運用の基本です。切り替え直前に TTL を 60 秒にしておけば、実際の切り替え時に素早く新しいアドレスへ移れます。

何層ものキャッシュ — ブラウザから再帰サーバまで

「DNS キャッシュ」というと再帰サーバのキャッシュだけを思い浮かべがちですが、実際には複数の階層にキャッシュが存在します。ひとつのドメイン解決要求は次のようなキャッシュの階段を経ます。

ブラウザキャッシュ -> OS(スタブリゾルバ)キャッシュ -> 再帰サーバキャッシュ -> 権威サーバ

(数十秒) (OS の設定) (TTL ベース) (最終的な答え)

各階層は自前で答えをキャッシュします。そのため権威サーバのレコードを変えても、ブラウザや OS のレベルが古い値を持っていれば変更がすぐには見えません。開発中に「確かに変えたのになぜ変わらない?」と慌てることの相当数が、この多層キャッシュのせいです。

こういうときは各階層を順に空にせねばなりません。

OS レベルの DNS キャッシュを空にする(OS ごとに異なる)

macOS の例

sudo dscacheutil -flushcache

ブラウザは自前のキャッシュを別に持つので別途空にする

(ブラウザ設定のネットワーク/セキュリティ項目で処理)

この多層構造を理解すれば、「伝播しない」という漠然とした不満の代わりに「どの階層のキャッシュが問題か」を正確に突き止められます。そしてそれがそのまま素早い問題解決につながります。

スタブリゾルバ — OS の中の小さな DNS クライアント

オペレーティングシステムにはスタブリゾルバ(stub resolver)という小さな DNS クライアントが入っています。アプリケーションがある名前の解決を頼むと、スタブリゾルバがその要求を受けて設定された再帰サーバへ送ります。つまり私たちが直接再帰サーバと通信するのではなく、OS のスタブリゾルバが仲介役を果たします。

スタブリゾルバは通常キャッシュも持ち、hosts ファイルのようなローカル設定も先に確認します。そのため hosts ファイルに項目を追加すれば、DNS 問い合わせなしに名前を解決できます。ローカル開発環境でドメインを偽装マッピングするときによく使う手法です。

レコードの種類 — 名前に込める多様な情報

DNS は単に名前を IP に変えるだけではありません。レコードタイプに応じてさまざまな情報を持ちます。

| タイプ | 用途 | 例の値 |

| ------ | --------------------------------- | --------------------------- |

| A | IPv4 アドレス | 93.184.216.34 |

| AAAA | IPv6 アドレス | 2606:2800:220:1:248:1893:: |

| CNAME | 別名への別称 | www -> example.com |

| MX | メールサーバ(優先度付き) | 10 mail.example.com |

| TXT | 任意のテキスト(SPF、検証など) | v=spf1 include:_spf ~all |

| NS | この領域を担当する権威サーバ | ns1.example.com |

| SOA | 領域のメタデータ(シリアル等) | プライマリ、更新周期など |

| CAA | 証明書発行を許可する機関の制限 | 0 issue letsencrypt.org |

CNAME には一つの落とし穴があります。ルートドメイン(example.com 自体)には CNAME を置けません。ルートには必ず SOA と NS レコードが必要ですが、CNAME は同じ名前に他のレコードが共存することを許さないからです。多くの DNS 事業者はこの問題を ALIAS または ANAME という非標準レコードで回避します。

dig で直接確認する

レコードを直接照会するには dig コマンドが最も便利です。

A レコードを照会

dig example.com A

特定の権威サーバに直接問い合わせ(キャッシュ回避)

dig @ns1.example.com example.com A

委任経路を段階的に追跡

dig +trace example.com

応答時間だけ素早く確認

dig example.com +stats | grep "Query time"

`dig +trace` は再帰サーバを経由せずルートから直接たどるため、委任がどこで途切れたかを診断するときに特に役立ちます。

逆引き DNS — IP から名前へ

ここまでは名前から IP を探す正引きだけを扱いましたが、その逆も可能です。IP アドレスから名前を探すことを逆引き DNS(reverse DNS)といい、PTR レコードを使います。逆引きは特別な領域である in-addr.arpa(IPv4)と ip6.arpa(IPv6)の下で行われます。

IP アドレスから名前を探す(PTR 照会)

dig -x 93.184.216.34

逆引き DNS は日常的なウェブ閲覧にはほとんど使われませんが、特定の領域では非常に重要です。代表的なのがメールサーバです。多くのメールサーバが、送信側 IP の PTR レコードが正しく設定されているかをスパム判別の一基準とします。正引きと逆引きが一致するか(forward-confirmed reverse DNS)を検査するのです。だから自前のメールサーバを運営するなら PTR 設定は選択ではなく必須です。

逆引き DNS はまた、ネットワーク診断やログ分析でも役立ちます。アクセスログに残った IP を人が読める名前に変え、どの組織から来たトラフィックかを推し量るのに役立ちます。

Anycast — ひとつの IP、世界中に分散

DNS の安定性と速度を支える核心技術が Anycast です。通常ひとつの IP アドレスはひとつのサーバを指しますが(Unicast)、Anycast では同じ IP を世界中の数十、数百のサーバが同時に広告します。

1.1.1.1 (同じ IP を世界中が広告)

ソウルの利用者 --+

| BGP が最も近い場所へルーティング

ソウルノード <--+

ロンドンの利用者 +

ロンドンノード <-+

(利用者は自分にネットワーク的に最も近いノードに到達)

これが可能なのはルーティングプロトコルである BGP のおかげです。同じ IP が複数の場所で広告されると、各ネットワークは自分に最も近い経路を選びます。結果としてソウルの利用者はソウルノードに、ロンドンの利用者はロンドンノードに到達します。

Anycast がもたらす利点は明確です。

- **遅延の減少**: 利用者は常に近いノードに接続します。

- **負荷分散**: トラフィックが自然に複数ノードへ分かれます。

- **障害の隔離**: あるノードが落ちても BGP が自動的に別ノードへ経路を再計算します。

- **DDoS の吸収**: 攻撃トラフィックが一箇所に集中せず世界中へ分散します。

8.8.8.8 や 1.1.1.1 のような公開 DNS がどこからでも速く応答する秘訣が、まさにこの Anycast です。

もちろん Anycast にも微妙な落とし穴があります。UDP のように状態を持たないプロトコルには理想的ですが、TCP のように接続状態を維持せねばならないプロトコルでは、経路が途中で変わると接続が別ノードへ向かって切れることがあります。DNS が主に短い UDP 問い合わせを使うため、この問題が大きく顕在化しないだけです。また、ある利用者が「最も近い」ノードに到達するかは純粋に BGP のルーティングポリシー次第で、地理的に近いノードが常にネットワーク的に近いわけではない点も覚えておく価値があります。

GeoDNS — 場所によって異なる答え

Anycast が「同じ答えを最も近い場所から与える」なら、GeoDNS は「場所によって異なる答えを与える」点で異なります。権威サーバが問い合わせを送った再帰サーバの位置(または EDNS Client Subnet 情報)を見て、地域ごとに異なる IP を応答する方式です。

アジアからの問い合わせ -> 権威サーバ -> A = アジアリージョンの IP

欧州からの問い合わせ -> 権威サーバ -> A = 欧州リージョンの IP

この手法は CDN やグローバルサービスが利用者を近いデータセンターへ送るのに広く使われます。ただし再帰サーバの位置と実際の利用者の位置が異なる場合があるという限界があり、EDNS Client Subnet という拡張で利用者のおおよその位置を権威サーバに伝えることもあります。

ここで Anycast と GeoDNS の関係を押さえておく価値があります。二つは競合する技術ではなく補完する技術です。Anycast は DNS 問い合わせ自体を近い権威サーバへ送って応答を速くし、GeoDNS はその応答の内容(どのデータセンターへ行くか)を位置に合わせて選びます。つまり「どこで答えるか」は Anycast が、「何を答えるか」は GeoDNS が担うわけです。現代の大型 CDN はこの二つを結合し、利用者が近い DNS ノードから近いコンテンツサーバのアドレスを速く受け取れるよう設計します。

GeoDNS にも落とし穴はあります。利用者が自分の位置から遠く離れた公開リゾルバを使うと(例: 海外 VPN を経由したり特定の公開 DNS を指定した場合)、権威サーバはそのリゾルバの位置を基準にして見当違いのリージョンの答えを与えることがあります。EDNS Client Subnet がこの問題を一部緩和しますが、プライバシー上の懸念でこの拡張を送らないリゾルバもあり、完全な解決策ではありません。

DNSSEC — 答えが偽造されていないことを証明する

基本的な DNS には致命的な弱点があります。応答に署名がなく、途中で答えを偽造してもクライアントが気づく方法がないことです。これを狙ったのがキャッシュポイズニングのような攻撃です。

DNSSEC は各レコードにデジタル署名を付けてこの問題を解決します。権威サーバはレコードに RRSIG(署名)を併せて提供し、上位領域は下位領域の公開鍵ハッシュを DS レコードで保証します。こうしてルートから権威サーバまで信頼の連鎖(chain of trust)が形成されます。

ルート(信頼の出発点)

| DS レコードで com の鍵を保証

com

| DS レコードで example.com の鍵を保証

example.com

| RRSIG で各レコードに署名

実際のレコード(偽造不可能)

DNSSEC は応答の完全性と出所を保証しますが、内容を暗号化はしません。つまり偽造した答えを与えることは防げますが、自分がどのドメインを照会しているかは依然として露出します。このプライバシー問題を解決するのが次に見る DoH/DoT です。

DNSSEC の導入は思ったより厄介です。鍵を周期的に交換(rollover)せねばならず、上位領域に DS レコードを正確に登録せねばならず、署名が満了する前に更新せねばなりません。この運用負担のため DNSSEC の導入率は期待ほど高くありません。署名の満了をうっかりしてドメイン全体が解決不能になる事故もまれではなく報告されます。セキュリティと運用の複雑さの間のトレードオフをよく示す事例です。

UDP から TCP へ — DNS 転送層の進化

伝統的に DNS は UDP 53 番ポートを使います。問い合わせと応答が通常一パケットに収まるほど小さいため、接続設定コストのない UDP が効率的でした。しかし応答が大きくなると話は変わります。

小さい応答(A レコード一つ): UDP 一パケットで十分

大きい応答(DNSSEC 署名込み): UDP 一パケットを超える -> 切り詰め(TC ビット) -> TCP 再試行

応答が UDP パケットサイズの限界を超えると、サーバは「切り詰められた(truncated)」という表示(TC ビット)を送ります。するとクライアントは同じ問い合わせを TCP で送り直します。DNSSEC 署名や大きな TXT レコードのように応答が大きくなる場合、この TCP フォールバックが頻繁に起きます。

この限界を緩和するために EDNS(Extension Mechanisms for DNS)が導入されました。EDNS はクライアントが「私はより大きな UDP 応答を受け取れる」と知らせ、不要な TCP フォールバックを減らします。また先に見た EDNS Client Subnet のような拡張オプションを運ぶ通路の役割も果たします。

EDNS バッファサイズを明示して問い合わせ(大きい応答の処理)

dig example.com A +bufsize=4096

DNSSEC 関連のレコードまで一緒に要求

dig example.com A +dnssec

実務で重要な点は、ファイアウォールが DNS の TCP 53 番や大きな UDP パケットを塞いでいると DNSSEC が動作しないことがある、ということです。「A レコードは引けるのに DNSSEC 検証だけ失敗する」なら、転送層のパケットサイズの問題を疑ってみる価値があります。

DNS 負荷分散 — ラウンドロビンとその限界

DNS は単純な負荷分散ツールとしても長く使われてきました。一つの名前に複数の A レコードを登録しておくと、権威サーバは問い合わせごとに順序を変えて応答するラウンドロビン(round-robin)を行います。

example.com. 60 IN A 192.0.2.10

example.com. 60 IN A 192.0.2.11

example.com. 60 IN A 192.0.2.12

問い合わせ 1 -> 10, 11, 12 の順で応答

問い合わせ 2 -> 11, 12, 10 の順で応答(循環)

この方式は設定が簡単という利点がありますが、限界も明確です。DNS は各サーバの実際の健康状態を知りません。あるサーバが落ちてもその IP を応答に含め続けることがあり、クライアントと再帰サーバが応答をキャッシュするため分散が均一ではありません。だから本格的な負荷分散は通常 DNS ではなく別のロードバランサ層で処理し、DNS は近いリージョンや入口へ送る役割までを担います。

ここで GeoDNS とヘルスチェックを結合した現代的な DNS サービスが登場します。これらは各エンドポイントの健康状態を周期的に点検し、死んだエンドポイントを応答から自動で外し、利用者の位置に応じて最も近い健全なエンドポイントを返します。単純なラウンドロビンを超えた、知的なトラフィック誘導の領域です。

DoH と DoT — 問い合わせそのものを暗号化する

従来の DNS は平文 UDP でやり取りされます。同じネットワークにいる誰かは、自分がどのサイトを訪れるかをそのまま覗けます。これを防ぐために登場したのが暗号化された DNS です。

- **DoT (DNS over TLS)**: 専用ポート(853)で TLS により DNS トラフィックを暗号化します。DNS トラフィックであることがポートで分かるため、管理者が識別してポリシーを適用しやすいです。

- **DoH (DNS over HTTPS)**: 一般的な HTTPS(443)上に DNS 問い合わせを載せて送ります。一般の Web トラフィックと区別しにくく検閲回避に有利ですが、同じ理由で企業網の管理者にとっては制御が難しい悩みの種でもあります。

DoH で問い合わせを送る(Cloudflare の例)

curl -H "accept: application/dns-json" \

"https://cloudflare-dns.com/dns-query?name=example.com&type=A"

DoH の登場は単なる技術的変化ではなく、制御権の移動でもあります。かつて DNS はネットワーク管理者が容易に観察し遮断できる地点でしたが、DoH はその制御権をアプリケーション(特にブラウザ)へ移しました。このためセキュリティとプライバシー、そして網管理の間の緊張は今なお続いています。

実務で DoH/DoT を導入するときは、一つのバランスを考えねばなりません。プライバシーは明確な利点ですが、社内 DNS ベースのポリシー(特定ドメインの遮断、内部専用名の解決など)が迂回されることがあります。だから多くの組織は信頼する社内リゾルバにのみ暗号化された DNS を送るよう設定し、プライバシーと制御を両立させようとします。暗号化そのものが目的ではなく、「誰を信頼するか」を明確にすることが核心です。

運用上の落とし穴 — 無料化時代にいっそう注意すべきこと

DNS ホスティングが無料になり参入障壁は下がりましたが、運用の落とし穴はむしろより頻繁に出会うようになりました。実務で繰り返される代表的なケースを整理します。

1. TTL を無視した緊急変更

障害対応でレコードを急いで変えたのに、既存の TTL が 24 時間で世界中のキャッシュがなかなか更新されない、という状況はよくあります。普段から主要レコードの TTL を適正水準(例: 300 秒)に保てば、緊急時に動ける幅が広がります。

2. ネガティブキャッシュ(NXDOMAIN)の罠

存在しないドメインを照会すると「なし(NXDOMAIN)」という答えもキャッシュされます。この否定キャッシュの期間は SOA レコードの最後のフィールドが決めます。新しいサブドメインを作ったのにしばらく見えない場合、否定キャッシュが原因のことが多いです。

3. 伝播(propagation)への誤解

「DNS が世界中へ伝播する」という表現は実は不正確です。権威サーバのレコードは変えた瞬間に更新されますが、各再帰サーバは自分がキャッシュした答えの TTL が終わって初めて新しい値を取得します。したがって「伝播遅延」の正体は、ほとんどがキャッシュ失効を待つ時間です。

4. CNAME チェーンと応答遅延

CNAME がさらに別の CNAME を指す長いチェーンは、再帰サーバに何度も問い合わせさせて最初の応答を遅くします。可能ならチェーンは短く保つのがよいでしょう。

5. 無料 DNS のロックインと可用性

無料サービスでも、それに全面的に依存すると、その事業者の障害がそのまま自分のサービスの障害になります。重要なサービスなら権威サーバを二つ以上の事業者に分散(セカンダリ DNS)することを検討する価値があります。無料化でコスト負担が減った分、むしろ冗長化を適用しやすくなったとも言えます。

6. ワイルドカードレコードの罠

ワイルドカードレコード(アスタリスクで始まるレコード)は、定義されていないすべてのサブドメインに同じ答えを与えます。便利ですが危険です。意図しないサブドメインまで全部応答するようになり、誤字や存在しない名前が見当違いのサーバへ向かうことがあります。またワイルドカードはより具体的なレコードがあればそれに隠されるなど、優先順位のルールが直感と異なって働く場合があるため、設定時に動作を正確に確認せねばなりません。

7. キャッシュの一貫性とマルチ事業者運用

権威サーバを複数の事業者に分散すると可用性は高まりますが、二つの事業者のレコードが常に一致するよう同期する作業が新しい課題になります。片方だけ更新してもう片方を忘れると、利用者ごとに異なる答えを受け取る混乱が生じます。こういう場合は一箇所を単一の真実の供給源(source of truth)として残し、残りを自動で同期する構造が安全です。

批判的視点 — タダの代償

DNS の無料化は確かに歓迎すべきことですが、一歩引いて見ると考えるべき点もあります。無料サービスが増えるほどトラフィックは少数の大手事業者に集中します。インターネットの最も基礎的なインフラが少数の手に集まることは、それ自体で中央集権化のリスクを高めます。ある大手 DNS 事業者の障害が世界中の多くのサービスを同時に止めた過去の事例がこれをよく示しています。

また「無料」はしばしばデータで支払われます。誰がどのドメインをどれくらい頻繁に照会するかは、それ自体が貴重な情報です。無料 DNS を選ぶとき、事業者のデータポリシーを確認することが重要なのはそのためです。

実務適用 — DNS デバッグ実践

理論を知ったので、実際に問題が起きたときどう診断するかを整理してみましょう。DNS の問題は症状が曖昧で、見当違いの場所をさまよいやすいです。体系的なアプローチが時間を節約してくれます。

症状別の診断表

| 症状 | 疑うべき箇所 | 確認方法 |

| ----------------------------- | ----------------------------- | --------------------------------- |

| 一部の利用者だけ接続不可 | 特定の再帰サーバの古いキャッシュ | 複数の公開リゾルバで照会を比較 |

| 変更が反映されない | TTL 失効待ち | 権威サーバへの直接問い合わせを比較 |

| 新しいサブドメインが見えない | NXDOMAIN の否定キャッシュ | SOA 最後のフィールドと時間を確認 |

| たまに遅い応答 | CNAME チェーン、TCP フォールバック | 応答時間とレコードチェーンを追跡 |

| DNSSEC 検証だけ失敗 | 署名満了、パケットサイズの問題 | dig +dnssec で署名を確認 |

段階別の診断手順

まず最初にすべきことは「権威サーバの本当の答え」と「再帰サーバが与える答え」を分離することです。二つが異なればキャッシュの問題で、同じなら設定の問題です。

1 段階: 再帰サーバ(既定のリゾルバ)が与える答え

dig example.com A

2 段階: 権威サーバに直接尋ねた本当の答え

dig @ns1.example.com example.com A

3 段階: 複数の公開リゾルバを比較(伝播状態を確認)

dig @8.8.8.8 example.com A

dig @1.1.1.1 example.com A

4 段階: 委任経路全体を追跡

dig +trace example.com

1 段階と 2 段階の答えが異なれば、再帰サーバが古い値をキャッシュしているという意味です。TTL が終わるのを待つか、キャッシュを空にできるなら空にします。答えが同じなら、権威サーバのレコード自体を点検せねばなりません。

DNS 設計チェックリスト

新しいサービスの DNS を設計するとき点検すべき項目を整理すると次のようになります。

1. **主要レコードの TTL を適正水準に**: 変更の可能性があるレコードは 300 秒前後に保ちます。

2. **権威サーバの冗長化**: 可能なら二つ以上の事業者に権威サーバを分散します。

3. **CNAME チェーンの最小化**: ルートドメインには CNAME の代わりに ALIAS/ANAME または A レコードを使います。

4. **メールセキュリティレコードの点検**: SPF、DKIM、DMARC を TXT レコードで正しく設定します。

5. **CAA レコードで証明書発行を制限**: 許可された認証機関だけが証明書を発行するよう塞ぎます。

6. **モニタリング**: 外部から周期的に主要レコードを照会し、可用性と正確性を監視します。

この中でも権威サーバの冗長化は無料化時代に特に実践しやすくなりました。コスト負担が減った分、互いに異なる事業者に権威サーバを置いて単一障害点をなくす設計が現実的な選択肢になりました。

おわりに

DNS はインターネットで最も古く、最も当たり前とされている技術ですが、その内部は再帰と委任、キャッシュと TTL、Anycast と GeoDNS、そして DNSSEC と暗号化された転送まで、驚くほど精緻な分散システムです。無料化という表面的な出来事をきっかけにその深部を再び覗くことは、LLM 時代に「深く理解すること」の価値が再評価される流れとも通じています。

ツールがタダになり抽象化が厚くなるほど、その下で実際に何が起きているかを知る人の価値はむしろ高まります。次にブラウザにドメインを入力するとき、その短い一瞬に広がる世界規模の協調の風景を一度思い浮かべてみてください。

DNS を深く理解することの報酬は明確です。障害が起きたとき、他の人が漠然と「DNS の問題のようだ」と言うとき、あなたは「再帰サーバのキャッシュが古い値を持っていて、TTL が二時間残っている」と正確に突き止められます。新しいサービスを設計するとき、権威サーバの冗長化と適正な TTL、PTR と CAA まで漏れなく押さえられます。こうした具体的な理解は、抽象化の上にさらに抽象化を積む時代にむしろより希少で価値ある資産になります。

無料化は終わりではなく始まりです。参入障壁が下がった分、いま差を生むのはツールを使えるかではなく、ツールがすることを理解しているかです。この記事がその理解への小さな足がかりになっていれば幸いです。

参考資料

- [RFC 1034 — Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034)

- [RFC 1035 — Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035)

- [RFC 4033 — DNS Security Introduction and Requirements (DNSSEC)](https://datatracker.ietf.org/doc/html/rfc4033)

- [RFC 8484 — DNS Queries over HTTPS (DoH)](https://datatracker.ietf.org/doc/html/rfc8484)

- [RFC 7858 — DNS over Transport Layer Security (DoT)](https://datatracker.ietf.org/doc/html/rfc7858)

- [Cloudflare Learning — What is DNS?](https://www.cloudflare.com/learning/dns/what-is-dns/)

- [Cloudflare Learning — What is Anycast?](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/)

- [Hacker News](https://news.ycombinator.com/)

- [GeekNews](https://news.hada.io/)