## この記事でわかること

- DNS インフラの「健全性」を構成する 5 つの観点（冗長性・DNSSEC・CAA・IPv6・応答速度）
- ネームサーバーが 1 台しかない、または 1 事業者に集中している場合のビジネスリスク
- Web 担当者が今すぐ確認すべき項目と、必要に応じて検討すべき項目の線引き

## DNS インフラの健全性とは

DNS（ドメインネームシステム）はインターネットの住所録の仕組みで、ドメイン名を IP アドレスやメールサーバー名に変換します。普段意識することはほぼありませんが、DNS が落ちるとサイトもメールも一斉に止まる、極めて影響範囲の広いインフラです。

「DNS が動いている」だけでは健全とは言えません。本記事では、DNS インフラの健全性を以下の 5 つの観点で整理します。

![DNSインフラの健全性チェック5観点](/blog/dns-infra-health/dns-health-overview.svg)

- **NS 冗長性**: ネームサーバーが複数台あり、事業者も分散しているか
- **DNSSEC**: DNS 応答の改ざんを検知できる仕組みが有効か
- **CAA**: SSL 証明書を発行できる認証局を制限しているか
- **IPv6（AAAA）**: IPv6 環境からのアクセスに対応しているか
- **応答速度**: ユーザーから見て十分に速く名前解決できているか

それぞれ重要度と現場の実務インパクトが違うので、順に見ていきます。

## NS の冗長性｜「ネームサーバー 1 台」の落とし穴

DNS 健全性のなかで最も影響が大きいのが、**ネームサーバー（NS）の冗長性**です。RFC 1034 では権威 DNS サーバーを少なくとも 2 台用意することが強く推奨されており、現代のクラウド型 DNS サービスはほぼすべて、複数台の Anycast ネットワークで提供されています。

### 1 台運用がなぜ危険か

NS が 1 台しかない、もしくは複数台あってもすべて同じデータセンター・同じ事業者に乗っている場合、**その 1 つに障害が起きるとドメイン全体が引けなくなります**。具体的には、サイトが見られない、メールが送受信できない、SaaS のシングルサインオンが通らない、といった全停止が同時に発生します。

![NS1台 vs 複数台＋事業者分散の障害シナリオ比較](/blog/dns-infra-health/ns-redundancy.svg)

過去にも 2016 年の Dyn DNS 大規模障害（Twitter・Spotify・GitHub など多数のサービスがダウン）など、特定の DNS 事業者の障害が広範囲に影響する事例があります。中小企業は被害規模では報道されにくいだけで、同じ構造のリスクを抱えています。

### 現実解

レンタルサーバー付属の DNS をそのまま使っているケースが多いと思いますが、以下のいずれかであれば最低限の冗長性は確保できています。

- Cloudflare、Route 53、Google Cloud DNS などのクラウド DNS（標準で複数拠点構成）
- 主要レンタルサーバー（さくら・エックスサーバー・ConoHa など）の DNS（複数台構成）

逆に、自社サーバーで BIND を 1 台だけ動かしている、特定の小規模事業者の DNS を 1 系統だけ使っている、といった構成は早めの見直しを推奨します。事業者を 2 系統に分散させる Multi-DNS 構成は、可用性を更に高める選択肢です。

## DNSSEC と CAA｜なりすまし対策の追加レイヤー

### DNSSEC（DNS Security Extensions）

DNSSEC は DNS 応答に電子署名を付け、途中で改ざんされていないかを受信側で検証できる仕組みです。RFC 4033〜4035 で定義されています。

導入されていれば、利用者の経路上で「偽の IP アドレス」を返すような攻撃（DNS キャッシュポイズニング）を検知できます。一方で、設定ミスでチェーンが切れると **DNS 応答自体が失敗（SERVFAIL）** してドメイン全体が引けなくなる事故が起きやすく、運用には専門知識が必要です。

判断基準としては「メールサービスや認証基盤が DNSSEC 検証に依存しているか」で考えると整理しやすいです。Google Workspace や Microsoft 365 の標準利用範囲では必須ではないため、導入は任意です。

### CAA（Certification Authority Authorization）

CAA は「このドメインに対する SSL 証明書を発行できる認証局はここだけ」と DNS で宣言するレコードです。RFC 8659 で標準化され、2017 年 9 月以降は全公的 CA が証明書発行前に CAA を確認することが義務づけられています。

設定例: `0 issue "letsencrypt.org"` のように記述すると、Let's Encrypt 以外の認証局からの不正な証明書発行を CA 側でブロックできます。

CAA 未設定だと「どの CA でも発行可能」とみなされます。コスト負担なく追加できる対策なので、自社で利用している CA（Let's Encrypt、Sectigo、DigiCert など）を CAA で明示しておくことを推奨します。SSL 証明書の管理全般は [SSL 証明書の有効期限を確認する 3 つの方法](/blog/ssl-expiration-check) も参照してください。

## IPv6（AAAA）と応答速度｜現代の最低要件

### IPv6 の実務インパクト

IPv4 アドレスはすでに枯渇しており、モバイル回線や一部の海外環境では IPv6 が標準になっています。AAAA レコードを持たない（IPv6 で引けない）ドメインは、一部のユーザーから「遅い」「繋がりにくい」と感じられる可能性があります。

ただし IPv6 対応の主な責任はサイトをホストするサービス側にあり、Cloudflare、AWS、主要レンタルサーバーは標準で IPv6 対応しています。自社で IPv6 サーバーを立てるよりも、IPv6 対応済みのサービスを利用するほうが現実的です。

### 応答速度

DNS 応答が遅い（数百ミリ秒以上かかる）と、ページ表示やメール配送のレスポンスに直接響きます。特に海外取引のある会社では、海外拠点からの解決速度に注意が必要です。

クラウド DNS は世界中の Anycast 拠点から応答するため、地理的にも安定して数十ミリ秒以内に解決できます。応答速度に問題を感じている場合、まずは DNS 提供元を見直すと改善することが多いです。

DNS の基本的なレコード種類については [DNS レコードの種類をわかりやすく](/blog/dns-record-types) で詳しく解説しています。

## まとめ｜健全性を保つ優先順位

中小企業が DNS インフラの健全性を担保する優先順位は、以下のように整理できます。

- **最優先**: NS の冗長性確認。1 台運用や 1 事業者集中になっていないかチェック
- **コスト負担なく追加可能**: CAA レコード、信頼できるクラウド DNS への移行
- **判断ポイント**: DNSSEC は依存サービスを確認した上で検討。IPv6 はサービス側の対応で十分
- **継続監視**: 応答速度を定期的にチェック

NS 冗長性が「1 台 / 1 事業者」になっている状態は、地味ですが事業継続性の最大リスクの 1 つです。気づいたら早めに改善することを推奨します。

## まずは現状を把握しましょう

[無料のドメイン診断](/diagnose) では、NS の冗長性・事業者分散・DNSSEC・CAA・IPv6・応答速度の 6 観点をまとめてチェックできます。設定状況がひと目で把握できるので、対策の優先順位を考える出発点としてご活用ください。

「自社の DNS 構成を見直したいが、どこから手を付けるべきか判断しにくい」という場合は、[お問い合わせ](/contact) から専門家にご相談いただけます。現在の構成のリスクを整理し、現実的な改善案をご提案します。