全体像（舞台設定）
-
A社は中規模（従業員500名）。ネットワークは図1・表1で示され、社外に公開Web、社内に業務・内部Web・内部DNS、DMZに公開系を配置。外部DNSサーバは「権威DNS」兼「フルサービスリゾルバ（再帰解決）」として使われています（ここが重要な伏線）。
-
ブラウザの名前解決はプロキシが外部DNSへ投げる設定。加えて、プロキシとメールサーバが“フルリゾルバ”としても動作します。DNSソフトはOSSの“Dソフト”。
-
FWルール（表2）では、外部DNSサーバ⇄インターネットのDNSが双方向で許可（項番5・6）。最後はデフォルト拒否。
まず「リスク整理」と「基本設計変更」の筋
ニュースを受けて、M主任がDNSのリスクと対策を検討。とくに“外部DNSサーバ”が狙われやすいので、機能分割（権威DNSとフルリゾルバを分離）とFW見直しを提案する流れです。
リスク1：踏み台（反射型DoSに使われる）
-
送信元IPを偽装したDNS問い合わせを外部DNSへ送られると、第三者へ大量パケットを反射できてしまう、という典型的な「DNSリフレクション」問題。
-
対策案：外部DNSを廃止し、DMZに権威DNS（DNS-K）とフルリゾルバ（DNS-F）を新設。合わせてFWを「DNS-F→インターネットの問い合わせ」「インターネット→DNS-Kへの問い合わせ」だけ通す形に変更（表3のa,bにそれぞれDNS-F／DNS-Kが入る想定）。これで“外向き再帰”や“外部からリゾルバ利用”を遮断できます。
リスク2：DNSキャッシュポイズニング（リソースレコード改ざん）
-
フルリゾルバのキャッシュが汚染されると、たとえば「mailホストのAレコードのIP」を攻撃者のサーバに書き換えられ、メールが攻撃者へ流れる可能性。本文中“c レコードのIPアドレス”とあるのは実質Aレコード（mailのIP）を指します。
-
対策は3本立て（全部本文に出てきます）：
① 上の機能分割＋FW変更の流用（外部からリゾルバを使わせない）
② 送信元ポート番号のランダム化（取れる取れないの“推測”を困難にする）
③ DNSSEC（署名で送信者正当性と完全性を検証：鍵管理など運用負荷は増える）
リスク3：中間者攻撃によるDNS盗聴・改ざん
-
DNS over TLS（DoT）で“スタブリゾルバ↔フルサービスリゾルバ”間のDNS通信を暗号化する、が本文のポイント。どの区間を暗号化するのかが問われます。
設計案（ホスティング活用）の読み方
外部DNSに関する“その他のリスク”対策として、ホスティング上にDNSを置く2案を比較します。
案1：プライマリ権威は社内DMZのDNS-K、セカンダリ権威はX社のDNS-S、再帰はDNS-F（DMZ）
-
目的：権威DNSの冗長化＝単一障害点の低減。プライマリが止まってもセカンダリが引き継げる構成になります（本文の「下線③」で問うリスク低減の中身）。
-
ゾーン同期（転送）に伴う“情報流出リスク”は、転送許可を最小化するACLで抑える（表4）。許可／拒否を正しく読み取る問題が出ます。
-
図2（正引きゾーン抜粋）の読み方：NSレコードに“プライマリ（dns-k）”と“セカンダリ（dns-s.x-sha.co.jp）”を並記、MXは“mail.a-sha.co.jp”。X社側のゾーン名（x-sha.co.jp）やセカンダリのホスト名（dns-s）という条件に沿って字句を選びます。
案2：権威（DNS-HK/DNS-S）も再帰（DNS-HF）もホスティング側に集約
-
DMZにDNS-K/DNS-Fは置かない。FW（表5）は“社内からホスティングの再帰DNS（DNS-HF）へDNSを通す”のと“インターネットからホスティング上のセカンダリ権威（DNS-S）へDNSを通す”の2本が肝。社内でDNSを引く主体は“プロキシとメールサーバ”（＝スタブではなく自前で再帰する側）なので、その2台→DNS-HFを許可するのが読み筋です。
設問ごとの「何を聞かれていて、どこを拾うか」
（公式解答の写しではなく“拾い方”にフォーカスします）
-
設問1(1)
何を：外部DNSが止まった影響（A社“公開Web”への影響）。
拾う：外部DNSが“権威”も持っている点を押さえ、名前解決不可=公開Webへの到達に影響が出る、を30字で。 -
設問1(2)
何を：送信元IP偽装で踏み台にする攻撃名。
拾う：本文の“踏み台DoS”の典型＝DNSリフレクション。 -
設問1(3)
何を：表3のa,b（誰から誰へDNSを通す？）
拾う：リゾルバ（DNS-F）→外部、外部→権威（DNS-K）という役割分担を図示どおりに当てる。 -
設問1(4)
何を：メールサーバの“c レコード”のタイプ。
拾う：IPが書き換わるのはAレコード。本文の“mailのIP”という文脈から導く。 -
設問1(5)
何を：送信元ポート“d”の対策名。
拾う：キャッシュポイズニング対策の基本＝ランダム化。 -
設問1(6)
何を：署名で正当性/完全性検証する“e”の技術名。
拾う：DNSSEC（運用で鍵管理が要る点も本文あり）。 -
設問1(7)
何を：DoTが暗号化する“f–g”の通信区間。
拾う：スタブリゾルバ↔フルサービスリゾルバ。 -
設問2(1)
何を：下線③（プライマリ=DNS-K、セカンダリ=DNS-S）で“何のリスク”が下がる？
拾う：権威DNSの停止リスク（単一障害点）低減。 -
設問2(2)
何を：図2のh（NSの相手）・i（MXのホスト）。
拾う：hはセカンダリのFQDN（dns-s.x-sha.co.jp.）、iはmail.a-sha.co.jp. をMXで指す。本文の前提文（x-sha.co.jp／dns-s）も必読。 -
設問2(3)
何を：表4のゾーン転送ACL（j〜m）
拾う：DNS-K↔DNS-S間のみ“許可”、それ以外は“拒否”で最小化。 -
設問2(4)
何を：表5のn,p,o（誰がどこへDNS？）
拾う：社内の“プロキシ/メール”→ホスティングの再帰（DNS-HF）を許可、外部→権威（DNS-S）も許可という2本柱。
用語メモ（本文で区別が肝）
-
権威DNS：自ドメインの“正解”を持つサーバ（ゾーンファイルの原本）。
-
フルサービスリゾルバ：再帰解決を行う“DNSの案内人”。本文ではプロキシ/メールが利用。
-
スタブリゾルバ：PCやOSに入っている“簡易な問い合わせ役”。
-
DNSリフレクション：偽装元で第三者へ反射・増幅させるDoS。
-
キャッシュポイズニング：フルリゾルバのキャッシュ改ざん。
-
DNSSEC：署名で正当性と完全性を検証（鍵管理の運用が要る）。
-
DoT：スタブ↔フルのDNS通信をTLSで暗号化。
