情報処理安全確保支援士 2021年 春期 午後1 問02

解答の論理構成

1. 問題文の引用
   – 「①A社の外部DNSサーバがサービス停止になった場合の影響」
   – 表1「外部 DNS サーバ」は「A社ドメインの権威 DNS サーバ及び再帰的な名前解決を行うフルサービスリゾルバ」と記載。
2. 権威 DNS サーバが停止すると、インターネット上の利用者は a-sha.co.jp ドメインの名前解決を実行できない。
3. 「公開 Web サーバ」は a-sha.co.jp ドメイン配下にあるため、IP アドレスが引けず接続要求が届かない。
4. したがって公開 Web サーバが正常に稼働していても「名前解決ができなくなる」ことが直接的な影響となる。

誤りやすいポイント

• 「Web サーバが停止する」と誤記する。停止するのは DNS であり、Web サーバ自体は稼働している。
• 「アクセス不能になる」とだけ書き、原因である名前解決不可を示さない。
• 内部向け影響（PC からの閲覧など）と混同する。設問は公開 Web サーバへの影響を問う。

FAQ

解答の論理構成

1. 問題文は攻撃の流れを「②送信元のIPアドレスを偽装した名前解決要求を外部DNSサーバに送ることによって、外部DNSサーバを踏み台とし、攻撃対象となる第三者のサーバに対し大量のDNSパケットを送り付けるというDoS攻撃」と説明しています。
2. ポイントは
   • 「送信元のIPアドレスを偽装」＝攻撃対象に応答が返るようにする
   • 「外部DNSサーバを踏み台」＝DNSサーバを“反射鏡”として利用
   • 「大量のDNSパケットを送り付ける」＝トラフィック増幅によるDoS
3. これらの特徴は、DNSサーバにリクエストを送り込んで応答を被害者に反射させる「DNSリフレクション攻撃」と一致します。
4. よって解答は「DNSリフレクション攻撃」となります。

誤りやすいポイント

• 「DNSアンプ攻撃」と混同する
  増幅（Amplification）は確かに行われますが、本設問は“反射”の説明に焦点を当てており正式名称を求めています。
• 「Smurf攻撃」や「DDoS」とだけ回答する
  ICMPを使うSmurfや単なるDDoSではDNSを踏み台にする点が説明と一致しません。
• “IPスプーフィング攻撃”と書いてしまう
  IP偽装は手段であって攻撃種別名ではありません。

FAQ

解答の論理構成

1. 前提の整理
   問題文には、次のように役割分担が明記されています。
   「外部DNSサーバを廃止した上で、DNS-K と DNS-F というDNSサーバをDMZ上に新設し、権威DNSサーバの機能を DNS-K に、フルサービスリゾルバの機能を DNS-F に移行することを考えた。」
   つまり、 • DNS-K … 権威（公開応答用）
   • DNS-F … フルサービスリゾルバ（内部端末の名前解決代行）
2. 通信方向ごとの必要ルールを整理
   権威DNSは外部から問い合わせを受け付ける側、フルサービスリゾルバは外部へ問い合わせを発信する側です。したがって表3の2つのルールは次の対応になります。
   • 項番5 「送信元 → 宛先：インターネット」＝外向き通信
   外へ DNS パケットを出すのはフルサービスリゾルバ DNS-F。
   • 項番6 「インターネット → 宛先」＝内向き通信
   外部から DNS パケットを受けるのは権威DNS DNS-K。
3. よって
   a には フルサービスリゾルバ側の DNS-F、 b には 権威DNS側の DNS-K が入ります。
   以上より
   a：ア（DNS-F）
   b：イ（DNS-K）

誤りやすいポイント

• 「権威DNS＝外部へ応答」「フルサービスリゾルバ＝外部へ問い合わせ」という基本を逆に覚えていると、送信元と宛先を取り違えやすいです。
• 表2の旧ルールと頭の中で混在させてしまい、「外部DNSサーバ」と誤って選択するケースが散見されます。今回は外部DNSサーバを廃止する前提なので選択肢にありません。
• DMZ内に同居している他サーバ（公開 Web サーバやメールサーバ）の存在が紛らわしく、DNS以外の通信フローを思い浮かべてしまい選択を誤ることがあります。

FAQ

解答の論理構成

1. 問題文には「メールサーバのcレコードのIPアドレスが、例えば攻撃者のメールサーバのものに書き換えられてしまい」とあります。
2. DNSで「IPアドレス」を直接保持するリソースレコードは「A（Address）レコード」（IPv4の場合）です。
3. MXレコードはメールサーバを表しますが、値として記録するのはホスト名であってIPアドレスではありません。したがって、IPアドレスを書き換えるという記述に合致するのは A レコードです。
4. 以上より、c に入るタイプ名は「A」と結論付けられます。

誤りやすいポイント

• 「メール」と聞いて reflex 的に MX レコードを想起し、そのまま答えてしまう。MX はホスト名を返すレコードであり、IP アドレスが直接改ざんされる状況説明とは一致しません。
• IPv6 の AAAA レコードを選んでしまう。問題文には IPv6 を示す要素がなく、一般的に A レコードが前提となっています。

FAQ

解答の論理構成

1. 【問題文】には「二つ目の対策は、送信元ポート番号をdする対策である。」とあります。
2. DNSキャッシュポイズニング攻撃では、攻撃者はフルサービスリゾルバが外部の権威DNSサーバに送った問い合わせの「トランザクションID」と「送信元ポート番号」を推測して偽回答を送り込みます。
3. もし送信元ポート番号が固定（例：53番）であれば、攻撃者はトランザクションIDだけを推測すれば済むため攻撃が容易になります。
4. ポート番号を毎回異なる値にすれば、攻撃者は「トランザクションID＋ポート番号」の両方を当てる必要があり、成功確率が大幅に低下します。
5. このように問い合わせ時のポートをバラバラにする方法は「ソースポートランダム化」あるいは単に「ランダム化」と呼ばれ、典型的なDNSキャッシュポイズニング対策として広く採用されています。
6. したがってdに入る語は「ランダム化」となります。

誤りやすいポイント

• 「増加」「分散」といった曖昧な語を入れてしまう。対策の核心は“予測しにくくする”ことであり、キーワードは「ランダム化」です。
• DNSSECと混同する。DNSSECはリソースレコード自体に署名を付ける仕組みで、送信元ポート番号には触れません。
• “宛先”ポートをランダム化すると誤解する。DNS問い合わせで可変になるのはクライアント側の送信元ポートであり、宛先は権威DNSサーバの53番で固定です。

FAQ

解答の論理構成

1. 問題文は三つ目の対策について
   「三つ目の対策は、eという技術の利用である。」
   と述べています。
2. さらにその技術の機能を
   「この技術は、DNSサーバから受け取るリソースレコードに付与されたディジタル署名を利用して、リソースレコードの送信者の正当性とデータの完全性を検証するものである。」
   と説明しています。
3. ディジタル署名付きのリソースレコードにより“送信者の正当性（真正性）”と“データの完全性”を検証する DNS の拡張仕様は DNSSEC（Domain Name System Security Extensions）です。
4. DNSSEC はキャッシュポイズニング対策として代表的に挙げられる技術であり、条件「英字10字以内」にも合致します。
5. 以上より、e に入る語は DNSSEC となります。

誤りやすいポイント

• 「DoT」「DoH」など“通信を暗号化する”技術と混同する。問題文が要求しているのは署名検証による真正性･完全性担保であり、暗号化は論点外です。
• 「TSIG」を選ぶミス。TSIG はサーバ間のゾーン転送認証用で、利用範囲も限定的。リゾルバが受け取るリソースレコードの検証には用いません。
• “英字10字以内”という条件を見落とし、正式名称「Domain Name System Security Extensions」と書いてしまう。

FAQ

解答の論理構成

• 問題文では「DNS over TLS（以下、DoTという）という技術が標準化されている。DoTは、fとg間の通信を暗号化するために開発されたものである。」と記載されています。
• DoT が対象とするのは、PC やスマートフォンなどに入っている“軽量”な名前解決機能（スタブリゾルバ）と、再帰問い合わせを肩代わりする“フル機能”のリゾルバ（フルサービスリゾルバ）との間の経路です。
• スタブリゾルバは DNS クエリを生成する最初の主体であり、ここが盗聴・改ざんされると意図しない IP アドレスを取得してしまいます。そこで TLS によりこの区間を保護するのが DoT の目的です。
• フルサービスリゾルバと権威 DNS サーバ間の通信を暗号化したい場合は DoT ではなく DoH（DNS over HTTPS）や専用 VPN など別手段を選びます。
• 解答群から「スタブリゾルバ」は「オ」、「フルサービスリゾルバ」は「カ」であるため、 f：オ（スタブリゾルバ）
  g：カ（フルサービスリゾルバ）
  が正解となります。

誤りやすいポイント

• 「権威DNSサーバ」と間違える
  DoT は“クライアント～再帰サーバ”間を対象とする技術で、権威側のサーバは範囲外です。
• 「RADIUS」を選択してしまう
  RADIUS は認証プロトコルであり DNS とは無関係です。名称が TLS と紛らわしいため注意が必要です。
• 「DNS Changer」を選択してしまう
  マルウェア名であり、暗号化技術ではありません。

FAQ

解答の論理構成

• 【問題文】では、外部DNSサーバ1台に「権威 DNS サーバ及び再帰的な名前解決を行うフルサービスリゾルバ」の両機能を集約していると記載されています。
• ①で確認した影響は「A社の外部DNSサーバがサービス停止になった場合の影響」です。ここで指摘されているのは“可用性”の懸念です。
• ③の対応策は「プライマリの権威DNSサーバの機能をDNS-Kに、セカンダリの権威DNSサーバの機能をDNS-Sに移行」することです。権威 DNS を2台（DMZ 内とホスティングサービス上）に分散し、片方が停止してももう片方が応答できるようにします。
• したがって、③の実施で低減できるのは“権威 DNS サーバが1台しかなく、障害や攻撃で停止すると名前解決が不能になるリスク”となります。
• この内容を具体的にまとめると「権威DNSサーバがサービス停止になるリスク」という解答になります。

誤りやすいポイント

• 「DNS キャッシュポイズニング」「中間者攻撃」など他のリスクと混同し、可用性ではなく機密性・完全性に関する答えを書いてしまう。
• 「外部DNSサーバ全体がなくなるリスク」と漠然と書き、権威 DNS に絞った説明を欠いてしまう。
• “踏み台攻撃”を防ぐ変更と勘違いし、DoS の加害リスクを選んでしまう。

FAQ

解答の論理構成

1. 図2はA社ドメイン（a-sha.co.jp）の正引きゾーンファイルの抜粋です。NSレコードには「当該ゾーンを権威的に回答できるDNSサーバ」を列挙する必要があります。問題文では
   ―― 「③プライマリの権威DNSサーバの機能をDNS-Kに、セカンダリの権威DNSサーバの機能をDNS-Sに移行し」
   とあり、プライマリの “dns-k” は自社（a-sha.co.jp）、セカンダリ “dns-s” はホスティング先（x-sha.co.jp）に置く設計です。
   よってhには “dns-s”＋ホスティング先ドメイン＋終端の “.” を付けた 「dns-s.x-sha.co.jp.」 が入ります。
2. MXレコードにはメールを受け取るサーバのFQDNを指定します。問題文の記述
   ―― 「メールサーバのホスト名はmailであり、各サーバのIPアドレスはx1.y1.z1.t1～x1.y1.z1.t3である。」
   から、メールサーバ自体は従来どおり自社ドメイン配下です。従ってiには 「mail.a-sha.co.jp.」 を入れます。
3. 以上より、解答は
   h：カ 「dns-s.x-sha.co.jp.」
   i：ク 「mail.a-sha.co.jp.」

誤りやすいポイント

• NSレコードに “dns-k.” を二重に書き、セカンダリを漏らす。NSは最低でもプライマリ＋セカンダリを列挙する必要があります。
• 「dns-s.a-sha.co.jp.」を選んでしまう。セカンダリはホスティング先の “x-sha.co.jp” 配下であることを見落とすと誤答になります。
• MXレコードにホスト名「mail.」や「mail.x-sha.co.jp.」を記載してしまう。メールサーバが自社に残っている点を忘れないよう注意が必要です。

FAQ

解答の論理構成

1. 目的の再確認
   【問題文】には「ゾーン転送では、ゾーン情報が流出するリスクがある。」とあります。したがって、表4では“ゾーン転送要求に対する許可を必要最小限”に絞る必要があります。
2. 必要な通信経路の整理
   ・プライマリとセカンダリの関係は「③プライマリの権威DNSサーバの機能をDNS-Kに、セカンダリの権威DNSサーバの機能をDNS-Sに移行し」と明言されています。
   ・通常、セカンダリ（DNS-S）がプライマリ（DNS-K）に対してゾーン転送（AXFR／IXFR）を“要求”し、プライマリが応答します。
3. 行・列ごとの判定
   (1) ゾーン転送要求元がDNS-K → DNS-S（j）
   －プライマリからセカンダリへは “要求” ではなく通知（NOTIFY）や応答を返す側なので、転送“要求”は不要。
   －許可すると不要な経路が開くため拒否するのが最小構成。
   ⇒ j は「拒否」。
   (2) ゾーン転送要求元がDNS-S → DNS-K（k）
   －セカンダリがプライマリへ AXFR/IXFR を要求する正常経路。
   ⇒ k は「許可」。
   (3) ゾーン転送要求元がその他のIPアドレス → DNS-K（l）
   (4) ゾーン転送要求元がその他のIPアドレス → DNS-S（m）
   －第三者からの転送要求は情報流出リスクそのもの。
   ⇒ 両方とも「拒否」。
4. 以上より、 j：拒否
   k：許可
   l：拒否
   m：拒否

誤りやすいポイント

• “プライマリからセカンダリへデータを送る”と“プライマリが転送要求を出す”を混同し、jを許可にしてしまう。
• NOTIFY（更新通知）とAXFR/IXFR（転送要求）を同一視する。通知用のUDPパケットは拒否設定でも転送要求には影響しないと理解しておく。
• “その他のIPアドレス”行を空欄や許可にすると、公開リゾルバや攻撃者からのゾーン転送を許してしまい、本質的な対策にならない。

FAQ

解答の論理構成

1. 問題文は、二つ目の案について「外部DNSサーバを廃止した上で、DNS-HK,DNS-S,DNS-HFというDNSサーバをX社のホスティングサービス上に新設し、…フルサービスリゾルバの機能をDNS-HFに移行する」と明示しています。したがって、FWルール表5の宛先 o はフルサービスリゾルバである「DNS-HF」になります。
2. DMZ内にあった「プロキシサーバ」と「メールサーバ」は、インターネット上のホスト名解決を行う必要があります。フルサービスリゾルバを社内に置かないため、これらが直接「DNS-HF」に再帰問い合わせを行う構成となります。
   • プロキシサーバ：Webアクセス中継の際に外部ホスト名を解決する役割。
   • メールサーバ：SMTP 送信や受信時に MX / A レコードを引く必要あり。
   よって、表5の送信元は「プロキシサーバ」と「メールサーバ」であると判断できます。
3. 以上を対応づけると
   • 送信元 n ＝「プロキシサーバ」
   • 宛先 o ＝「DNS-HF」
   • 送信元 p ＝「メールサーバ」
   となり、模範解答の
   n：オ（プロキシサーバ）
   o：ア（DNS-HF）
   p：カ（メールサーバ）
   が導かれます。

誤りやすいポイント

• 「PC から直接 DNS-HF に問い合わせる」と考えて n や p に「PC」を入れてしまうケースがありますが、PC は HTTP/HTTPS を「プロキシサーバ経由」で行う設定になっており、DNSもプロキシに依存する前提です。
• 宛先 o を「DNS-S」と誤解するミス。DNS-S はセカンダリ権威 DNS であり再帰問い合わせには応答しません。あくまで再帰を担当するのは「DNS-HF」です。
• DMZ に DNS-K/DNS-F を残す旧構成と混同し、従来ルール（項番5,6）をそのまま当てはめてしまう誤答も散見されます。

FAQ