「仕組みは分かったけど、実際の設計ではどう考えればいいの？」
連載もいよいよ最終回です。第1回から第11回まで、DNSの仕組み・運用・調べ方・守り方・クラウドでの使い方・トラブルシュートを見てきました。最終回は、それらを実際の場面で使うための設計演習です。
5つの問題を用意しました。どれも現場で本当によく出会う状況をもとにしています。解答例を見る前に、ぜひ一度自分で考えてみてください。
演習の進め方
- 問題を読む：要件に線を引き、書かれていない条件は仮定する
- 5分考える：選ぶ案と、その理由を書き出す。可能なら、実際にdigで確かめる手順も書く
- 比べる：同僚やチームで共有できるなら、ほかの人の案と比べる
- 解答例と解説を読む：決め手になった要件を確認する
正解は1つではありません。どの要件を重く見たかで、選ぶ案が変わります。最初にすべきことは、要件と現状の確認です。問題文に書かれていない条件（体制、予算、将来の拡張）は、どう仮定したかを明記しましょう。答えを合わせるより、決め手になった要件を言えるようにすることが大切です。
問1 社内の新しいADドメイン名を決める
- 状況：従業員300名の会社で、ADのフォレストを新しく作ります。既存のADはなく、Microsoft 365（Entra ID）と連携する予定です
- 現状：自社は
example.co.jpを登録済みで、Webとメールに使っています（権威DNSは外部のDNSサービス） - 候補：①
corp.local②corp.internal③ad.example.co.jp - 環境：社内にはWindowsのほかにMacとLinuxサーバーがあり、社内のWebサイトにはTLSの証明書を使いたいと考えています
考えるポイント：端末の名前解決の経路、証明書の発行、クラウドとの連携、将来（合併や社名変更）への備え
問1 解答例と解説
| 案 | 長所 | 短所 |
|---|---|---|
| A corp.local | 短く、古い手順書と同じ | .local は mDNS 用（RFC 6762）で、Mac・Linux で引けないことがある。公的な証明書は取れない。Microsoft も非推奨 |
| B corp.internal | ICANN が内部用に予約（2024年）し、インターネットの名前と衝突しない | 公的な証明書は取れず、社内CAが必要。Entra ID 連携には別の UPN サフィックスが要る。合併先と同名の衝突は起こり得る |
| C ad.example.co.jp | 所有するドメインなので一意。Microsoft の推奨に沿う。証明書も選択肢が広い | 名前がやや長い。外部のDNSに同じ名前を作らない管理が必要 |
決め手は、クラウドとの連携、Mac・Linuxの混在、証明書の3つです。これらをすべて満たす案Cが有力です。案Bは、外部と完全に切り離した閉じた環境で、社内CAを運用できる場合の選択肢になります。
ADのドメイン名は後から変えるのが非常に難しいため、最初に決め切ります（第2回）。所有するドメインのサブドメインなら、衝突も証明書も連携も片付きます。
問2 Webサイトを別のサーバーへ移設する
- 状況：会社のWebサイト（
example.jpとwww.example.jp）を、オンプレのサーバー（198.51.100.10）から、クラウドの新しい環境（203.0.113.20）へ移設します - 現状：AレコードのTTLは86400秒（1日）です。権威DNSは自社で管理しています（プライマリ1台、セカンダリ1台）
- 要件：停止時間はできるだけ短くし、切り替えは来週土曜の夜に行います。問題があればすぐに元へ戻せるようにします
- 追加：新しい環境では
static.example.jpという名前も使い始めます。まだレコードはありませんが、テストのために何人かが引いてみたようです
考えるポイント：TTLをいつ・いくつに下げるか、旧サーバーをいつまで残すか、新しい名前の準備、切り戻しの方法
問2 解答例
| 案 | 内容 | 長所 | 短所 |
|---|---|---|---|
| A | TTL は変えず、当日に A レコードを書き換える | 手順が少ない | 最長1日、旧サーバーへ届き続ける。切り戻しにも同じだけかかる |
| B | 2日以上前に TTL を 300秒へ下げ、当日に書き換え、安定したら TTL を戻す | 切り替えと切り戻しが数分で効く。追加の費用がかからない | 事前の作業が必要。TTL を守らないキャッシュもあり、旧サーバーはしばらく残す |
| C | 案B に加え、切り替え後の旧サーバーを新環境への転送役（リバースプロキシ）にする | 古い答えを持つ利用者も新環境へ届き、実質的に停止がない | 構成が複雑になる。証明書、ログ、送信元 IP の扱いを別に考える |
基本は案Bで、停止を許されないサイトでは案Cを加えます。クラウドのDNSを使っている場合は、加重ルーティングで少しずつ新環境へ移す方法もあります（第10回）。どの案でも、static.example.jpのレコードは先に作っておきます。
問2 解説：移設のタイムライン
| 時期 | 作業 | ねらい・確認 |
|---|---|---|
| 1週間前 | 新環境と証明書を用意し、static.example.jp のレコードを作る | 事前の NXDOMAIN がネガティブキャッシュに残らないようにする |
| 2日前（旧 TTL の 86400秒より前） | example.jp と www の TTL を 300 に下げる（シリアルを上げる） | 1日の TTL で保存された古いキャッシュが切れるのを待つ |
| 当日（土曜夜） | A レコードを 203.0.113.20 に変更し、すべての NS で確認する | dig @各NS 名前 +norec（Resolve-DnsName -NoRecursion -Server）で NS 間の差をなくす |
| 切り替え後 数時間 | 旧サーバーのアクセスログを監視する | TTL を守らないキャッシュや、長く続く接続が残る |
| 1週間後 | 問題がなければ旧サーバーを止め、TTL を元に戻す（例：3600） | 切り戻しの可能性がなくなってから戻す |
最大の落とし穴は、TTLを下げる作業自体も、旧TTLの時間が経つまで効かない点です（第7回）。「前日にTTLを下げたから大丈夫」ではありません。
static.example.jpについては、テストで引いた人のキャッシュに「存在しない」が残っています。ネガティブキャッシュはSOAのTTLとMINIMUMの小さい方の時間だけ残るので、早めにレコードを作っておきます（第3回）。
なお、DNSサービスそのもの（NS）を移す場合は、親ゾーンのNSのTTLも考え、新旧のゾーンを同じ内容で並行稼働させます。
問3 オンプレとAWSの相互名前解決
- 状況：オンプレのADドメイン
corp.example.jp（DC兼DNSが2台）と、AWSの東京リージョンをDirect ConnectとVPNで接続しています。AWSには共有サービス用のアカウントが1つ、業務用のアカウントが3つあり、それぞれVPCを持っています - 要件①：オンプレの端末から、AWSの社内システム（
*.aws.corp.example.jp、プライベートホストゾーン）を引けること - 要件②：EC2（Windows）をADに参加させるため、VPCから
corp.example.jpを引けること - 要件③：DNSのために運用するサーバーは増やしたくない。業務用のアカウントは今後も増える予定です
考えるポイント：どの部品をどのアカウントに置くか、ルールをどう配るか、ループと冗長をどう防ぐか
問3 解答例
| 案 | 内容 | 長所 | 短所 |
|---|---|---|---|
| A | 共有サービス用アカウントに Resolver のインバウンド・アウトバウンドエンドポイントを置き、corp.example.jp の転送ルールを RAM（または Route 53 Profiles）で業務用アカウントへ共有。オンプレは aws.corp.example.jp をインバウンドへ条件付き転送 | サーバーの運用が要らない。アカウントが増えても関連付けるだけで済む | エンドポイントの IP ごとに料金がかかる。設定がオンプレと AWS に分かれる |
| B | EC2 に DNS サーバー（BIND、Unbound など）を立て、双方向の条件付き転送を行う | 細かく制御できる。費用が読みやすい | サーバーの冗長化・更新・監視が必要で、要件③に反する |
| C | AWS 上に DC を置き（EC2 または AWS Managed Microsoft AD）、VPC の DHCP オプションで DC を DNS に指定する | AD 参加と DNS が1か所で済む。回線が切れても AD が使える | プライベートホストゾーンや VPC エンドポイントの名前は、DC から VPC Resolver へ転送する設定が別に要る |
要件③から案Aが有力です。案CはDNSの方式というよりADの冗長の考え方で、案Aと組み合わせることもできます。
問3 解説
決め手は「DNSのサーバーを増やさない」「アカウントが増え続ける」という要件です。案Aでは、エンドポイントを共有サービス用アカウントに集め、転送ルールを他のアカウントへ共有します。ルールを関連付けるVPCどうしが、ネットワークでつながっている必要はありません。
注意点は3つです。
- ループ：オンプレは
aws.corp.example.jpをAWSへ、AWSはcorp.example.jpをオンプレへ、と向きを一方通行にする - 優先順位：同じ名前なら転送ルールがプライベートホストゾーンに勝つため、AWS側はサブドメインに分ける
- 冗長：エンドポイントは2つ以上のAZに置き、オンプレのDNSも2台とも転送先に登録し、回線ごとに片方を止めて試験する
NSレコードの委任（委任ルール）による連携も選べます（第10回）。つなぐ前に、名前ごとの向きと冗長の組を表にしておくと、設計の抜けが見つけやすくなります。
問4 「一部の利用者だけサイトが開けない」
- 状況：月曜の朝、ヘルプデスクに「取引先のポータル
portal.example.comが開けない」と連絡が5件ありました。ブラウザーには「サーバーのIPアドレスが見つかりませんでした」と表示されます - 報告者：本社の3名と、在宅勤務でVPNを使っている2名です。大阪拠点の人と、スマホの回線では開けます
- 社内の構成：本社にキャッシュDNS（BIND）が2台、大阪拠点に1台あり、どちらも社外の名前はルートから自分で解決しています。VPNの利用者は本社のキャッシュDNSを使います
- 取引先からは、先週末に「DNSサービスを移行した」と案内がありました
考えるポイント：どの順に何を確かめるか、考えられる原因は何か、取引先に何を伝えるか
問4 解答例と解説
| 案 | 内容 | 長所 | 短所 |
|---|---|---|---|
| A | 利用者に端末のキャッシュ消去や再起動を頼む | — | 原因がキャッシュDNS側なら直らない。原因も分からない |
| B | 困っている人の共通点（本社のキャッシュDNS）から、本社・大阪のキャッシュDNS と取引先の NS を dig（Windows は Resolve-DnsName）で順に比べる | 原因を特定でき、取引先に根拠を示せる | 手間がかかり、dig の知識が要る |
| C | 本社のキャッシュDNS のキャッシュをすべて消す、または再起動する | 一時的に直ることがある | 全社に影響し、原因の証拠も消える。DNSSEC の問題なら直らない |
答えは案Bです。第11回の「一部の人だけ引けない」の典型例ですね。
- 報告の共通点：本社のキャッシュDNSを使う人だけ（VPNの2名も本社のDNSを使う）
dig @本社DNSとdig @大阪DNSを比べる（SERVFAILとNOERROR）- EDEと+cdを確認する
dig +traceとdig @各NS +norecで取引先のNSを確認する
- EDE 22（No Reachable Authority）なら、本社だけが旧サービスのNSをキャッシュし、旧サービスがもう答えていない可能性が高い。
rndc flushtree example.comで該当部分だけ消す - EDE 9（DNSKEY Missing）なら、DSの更新漏れ。取引先にDSの修正を依頼する（第9回）
案Cの「全部消して再起動」は、直ることもありますが、原因の証拠も消えてしまいます。証拠を残したまま、原因の場所を1段ずつ絞りましょう。
問5 自社ドメインのメールとWebのDNS設定を見直す
- 状況：自社ドメイン
example.jpのDNS設定を、数年ぶりに見直すことになりました。担当者は何度も交代しています - メール：SPFに
include:が12個並んでいます。DKIMの署名は一部の送信サービスだけです。DMARCはp=noneのままで、レポートの送り先は退職者のアドレスです - Web：CAAレコードはありません。
campaign2019.example.jpなど、終了したキャンペーンのCNAMEが、クラウドのサービスを指したまま残っています - ドメイン：更新の支払いは前任者の名義のクレジットカードで、期限の通知メールも前任者のアドレスに届きます
考えるポイント：何から手を付けるか（リスクの大きい順）、メールを止めずに認証を強める手順、今後の管理のしかた
問5 解答例
| 案 | 内容 | 長所 | 短所 |
|---|---|---|---|
| A | DMARC をすぐ p=reject にし、SPF は使っていそうなものだけに削る | なりすましをすぐに防げる | 把握していない正規の送信が届かなくなる |
| B | 先にドメインの更新と CNAME の整理を行い、メールは DMARC のレポートで送信元を棚卸ししてから、段階的に強める | 事故を起こさず、リスクの大きい順に対処できる | 完了まで数週間〜数か月かかる |
| C | DNS の管理を外部の業者にまとめて任せる | 社内の手間が減る | 何が設定されているかを社内で把握できず、同じ問題が再発しやすい |
案Bが有力です。ドメインの失効とCNAMEの乗っ取りは、Webもメールも会社の信用も一度に失うため、最初に対処します。メールの認証は、止めてはいけない正規の送信を先に把握してから強めます。取り返せないものを先に直し、メールは送信元を把握してから強める、という順番です。
問5 解説：見直しのチェックリスト
| 項目 | 見直した後の姿 | 理由 |
|---|---|---|
| ドメインの更新 | 法人名義・自動更新。通知は共有アドレス。レジストラーのアカウントは多要素認証 | 失効すると Web もメールも止まり、第三者に取得される（第9回） |
| 使われていない CNAME | 参照先が無くなった CNAME を削除し、作るときに担当と終了日を台帳に残す | 参照先を他人が取ると、サブドメインを乗っ取られる（第9回） |
| SPF | 送信元を棚卸しし、DNS を引く回数を10回以内にする | 10回を超えると SPF の評価がエラーになる（RFC 7208） |
| DKIM | すべての送信サービスで、自社ドメインの鍵で署名する | 鍵は 2048 ビットを推奨。使わないセレクターも整理 |
| DMARC | レポート先を共有アドレスにし、none → quarantine → reject と段階的に強める | 2026年に RFC 9989 として標準化（pct タグは廃止） |
| CAA | 使う CA だけを issue で許可し、iodef で通知先を指定 | 2026年3月から、CA は DNSSEC が有効なドメインでは検証も行う |
レコードの書き方は第5回・第6回、テイクオーバーとドメインの失効は第9回で扱いました。この見直しは、大手のメール事業者の送信者ガイドライン（2024年〜）への対応にもなります。
連載を終えて
5つの問題、いかがでしたか。どの問題も、答えを知っているかどうかより、「どの要件が決め手か」「いま、どのDNSに、何を聞いているか」を言えるかどうかが大事でした。
12回にわたって、DNSの仕組みから調べ方・守り方・クラウドでの使い方までを見てきました。DNSは普段は意識されない存在ですが、止まったり誤った答えを返したりすると、あらゆる通信が入口で止まります。この連載が、「DNSがおかしいみたいです」と言われたときに、落ち着いて切り分けるための手がかりになればうれしいです。
まずは自分の端末でdig +traceを実行して、毎日使っている名前の委任をたどってみてください。きっと、これまでとは違う景色が見えるはずです。
最後まで読んでいただき、ありがとうございました。
コメント