ネットワークスペシャリスト 2016年 午後1 問03

解答の論理構成

1. a を特定
   • 引用：
     「ゾーン情報の更新時には、プライマリDNSがセカンダリDNSへ更新通知（NOTIFYメッセージ）を送信する。これを契機として、aが行われる。」
   • 解説：DNSではプライマリからセカンダリへ変更を反映させる手順を「ゾーン転送」と呼びます。NOTIFYメッセージはセカンダリに対し「最新データを取りに来て」と促すトリガです。したがって a ＝ ゾーン転送。
2. b を特定
   • 引用（表1項番1,2）：
     「送信元 MGW1,2 ― 宛先MSV1」「送信元MSV1～3 ― 宛先 MGW1,2」
   • 解説：MGW（メールゲートウェイ）とMSV（メールサーバ）は相互にメールを中継します。メール転送に使われる標準プロトコルはSMTP（Simple Mail Transfer Protocol）です。POPやIMAPはクライアントがメールを取得するときのプロトコルであり、サーバ間転送には用いません。したがって b ＝ SMTP。
3. まとめ
   • a = ゾーン転送
   • b = SMTP

誤りやすいポイント

• NOTIFYのあとに「IXFR（差分転送）」と答えてしまう
  → 問題文は転送方式まで聞いておらず、包括的な処理名「ゾーン転送」が正解です。
• MGWとMSV間のプロトコルをPOP3／IMAP4と誤答
  → どちらもクライアント取得用。サーバ間の配送はSMTPが基本です。
• DNSの用語で「レジストリ更新」「再帰問い合わせ」を連想
  → いずれもゾーン転送とは別概念。トリガ条件と対象処理を区別しましょう。

FAQ

解答の論理構成

• 表1の項番3は
  「送信元DNS3／宛先 c／プロトコルDNSプロトコル」
  と記載されています。
• 【問題文】には
  「プライマリDNSはDNS1である。DNS3は公開ゾーン情報だけを保有するセカンダリDNSである。」
  とあります。また、
  「プライマリDNSは、セカンダリDNSとだけ通信を行う。ゾーン情報の更新時には、プライマリDNSがセカンダリDNSへ更新通知（NOTIFYメッセージ）を送信する。」
  と明記されています。
• NOTIFY受信後、セカンダリ側（DNS3）は最新ゾーン情報を取得するため 自身からプライマリへ AXFR/IXFRを要求します。このときの通信方向は
  「DNS3 → DNS1」
  です。
• したがって、FWで許可すべき「宛先」はプライマリである DNS1 となります。

誤りやすいポイント

• 「NOTIFYはプライマリ発信だから通信方向はDNS1 → DNS3」と早合点し、FWの戻り通信を考慮し忘れる。実際のゾーン転送はセカンダリ発信です。
• 「DNS2もセカンダリだから同じ扱い」と思い込み、宛先をDNS2としてしまう。項番3の送信元はDNS3なので対応するプライマリはDNS1です。
• ステートフルインスペクションを過信し、「戻りパケットが許可されるから送信元・宛先は逆でも良い」と勘違いする。あくまで“開始方向”を正しく設定する必要があります。

FAQ

解答の論理構成

1. 表1の項番4は
   「送信元：DNS1」「宛先：DNS3」「プロトコル：DNSプロトコル」
   と規定されています。
2. 【問題文】の〔現行NWの仕様〕(1) には
   「DNS1はプライマリDNS」「DNS3は公開ゾーン情報だけを保有するセカンダリDNS」とあり、さらに
   「ゾーン情報の更新時には、プライマリDNSがセカンダリDNSへ更新通知（NOTIFYメッセージ）を送信する」
   と明示されています。
3. よって、項番4の通信でDNS1からDNS3へ送られるのは「公開ゾーン情報」の「更新通知（NOTIFYメッセージ）」であると結論づけられます。

誤りやすいポイント

• DNS3が保持するのは「公開ゾーン情報」であり、社内向けの非公開ゾーン情報ではない点を見落としやすいです。
• 「ゾーン情報そのもの」ではなく「ゾーン情報の更新通知（NOTIFY）」が送られることを取り違えるケースが散見されます。
• DNSの“ゾーン転送”と“更新通知”を混同し、AXFR/IXFRと誤答してしまうことがあります。

FAQ

解答の論理構成

• 【問題文】では「MGWからMSVへのメール転送は、DNSラウンドロビンを用いても、負荷の偏りが生じやすい」と述べています。これは本来、複数IPへの問い合わせ結果を回転させることで均等化を図る方式です。
• ところがDNSラウンドロビンは「送信元が少数」のときに弱点が出ます。少数の送信元はたまたま得た同一IPをそのまま DNSキャッシュ に保持し続けるため、転送先を変えません。
• すると各送信元がずっと同じMSVを選び続けるので、サーバ間に「宛先の偏り」が固定化されてしまいます。
• この“固定化”はDNSレコードのTTL（生存時間）が切れるまで続くため、偏りが長時間継続します。
• 以上より
  ・条件：送信元が少数の場合
  ・理由：送信元は、DNSのキャッシュが生存している間、宛先を変えないから
  が解答となります。

誤りやすいポイント

• 「MGWが2台だから偶然片寄るだけ」と誤解し、DNSキャッシュの存在を忘れる。
• 条件を「メール送信が集中した場合」としてしまい、送信元数ではなくトラフィック量を基準に書いてしまう。
• TTLの長短に触れず「キャッシュされるから」とだけ述べ、偏りが“継続”する根拠を示さない。

FAQ

解答の論理構成

1. 【問題文】には
   　　“・ d と e に、VRRPを2グループ設定する。それぞれのグループをVRRPg1, VRRPg2と呼ぶ。”
   　とあります。VRRPを構成できるのは、同じセグメント上で冗長化・負荷分散を行う2台の装置です。図2で同一セグメントに並び、メール処理を行う2台は「新MSV1」「新MSV2」のみです。
2. さらに
   　　“・VRRPg1は d の優先度を高く設定し、VRRPg2は e の優先度を高く設定する。”
   　と記載されています。片方のグループでは「新MSV1」がMaster、もう片方では「新MSV2」がMasterになるよう優先度を逆転させる典型的なVRRPロードバランシング構成で、これも “新MSV1 ⇔ 新MSV2” でなければ成立しません。
3. したがって
   　d：新MSV1
   　e：新MSV2
   　が正答となります。

誤りやすいポイント

• 「VRRPはルータだけ」と決めつけ、MGW1/MGW2を選択してしまう。VRRPはL3動作が可能なサーバOSでも利用できます。
• “優先度を高く設定” の記述に気を取られ、Master側＝高負荷側と誤解して優先度を同一装置に統一してしまう。実際はグループごとにMasterを振り分けて負荷を分散します。
• DNSラウンドロビンとVRRPを同時に使う説明から、DNS3などDMZ側を連想してしまう。問題文は “PCのメールソフト” との通信経路に限定しており、DMZ機器は対象外です。

FAQ

解答の論理構成

1. PCが参照するホスト名を確認
   ― 仕様(2)に「PCのメールソフトのメール送受信サーバには、msvc を設定する。」とある。したがってAレコードのホスト名は msvc で固定される。
2. VRRPの仮想IPを確認
   ― 同じ仕様に「VRRPg1の仮想IPアドレスは VIP1, VRRPg2の仮想IPアドレスは VIP2 である。」と明記されている。
3. DNSラウンドロビン併用の目的
   ― 「新MSV1, 2とも正常時には、PCからのアクセスが分散し、一方の故障時には他方だけアクセスが行われるように、VRRPとDNSラウンドロビンを併用する。」とある。
   ― VRRPだけでは“片系障害時の冗長”は担保できるが“正常時の負荷分散”は行えない。そこでDNSラウンドロビンを用い、同一ホスト名 msvc に複数のIPを登録して同確率に返すことでアクセスを分散させる。
4. 結論
   ― ホスト名 msvc に対し、仮想IP VIP1 と VIP2 の2件のAレコードを登録すれば、DNSでの負荷分散とVRRPによる冗長の両要件を同時に満たす。

誤りやすいポイント

• 「新MSV1」「新MSV2」それぞれの実IP (IP1, IP2) を登録してしまう
  実IPはVRRP切替えの対象外のため、障害時に片系へ流れない。
• 別々のホスト名（例：msv1, msv2）でAレコードを作成する
  PCは msvc しか問い合わせないため、負荷分散が働かない。
• MXレコードの変更と混同する
  本問は「社内ゾーン情報のAレコード」に限定しており、メール配送用途のMXレコードとは別の話である。

FAQ

解答の論理構成

• 変更点の前提
  〔MSVの移行〕では「旧MSVと新MSVとを並行稼働させる。すなわち、旧MSV、新MSVとも、社内・社外宛てのメール送信、及び社内・社外からのメール受信を可能にする。」と明記されています。したがって、DMZ内の「MGW1,2」と「新MSV1, 2」の間でSMTP通信を双方向に通過させる必要があります。
• 現状の通信許可範囲
  〔現行NWの仕様〕の (5) と「表1 DMZ上の機器とMSV及びDNSとの間で許可されている通信」によれば、
  ・項番1：送信元「MGW1,2」→宛先「MSV1」→プロトコル「b」
  ・項番2：送信元「MSV1～3」→宛先「MGW1,2」→プロトコル「b」
  となっており、SMTPは「MSV1」にしか到達しません。
• 移行中に必要な変更
  「新MSV1, 2」を追加するだけではFWが新しいIPを通さないため、「ステートフルインスペクション」を用いているFWの許可リストを修正しなければ通信が確立しません。DNSやMGW自体の設定は設問条件にて除外されています。よって、設定変更が必要な現行機器は「FW」だけです。
• 変更内容の具体化
  「送信元MGW1,2 → 宛先 新MSV1,2」および「送信元 新MSV1,2 → 宛先MGW1,2」のSMTPを許可するルールを追加すれば要件を満たすため、解答は下記となります。

誤りやすいポイント

• 「LDAPを参照してメールルーティングを行う」のでLDAP側を変更すると誤解しがちですが、設問は「DNSとMGW以外で」と限定しており、LDAPの機能追加は不要です。
• 旧MSVを残したまま並行稼働すると「MSV1～3の許可が既にあるから大丈夫」と思い込みやすいですが、新MSVは別IPなのでFWルールを追加しなければSMTPは遮断されます。
• DNSレコード追加とFWルール追加を混同しやすい点にも注意が必要です。DNSは名前解決、FWは経路制御を担当する別レイヤです。

FAQ

解答の論理構成

1. 移行工程では「メール送受信サーバの変更を実施済みの社員と、未変更の社員（以下、未変更社員という）が混在する。」という状態が【問題文】に明記されています。
2. さらに、「旧MSV、新MSVとも、社内・社外宛てのメール送信、及び社内・社外からのメール受信を可能にする。」とも書かれており、新MSVが社外メールも一手に受け取る可能性があります。
3. したがって、新MSVには
   　・メール送受信サーバを新MSVに切替済みの社員から送られる社内メール
   　・社外から届く社内宛てメール
   　の両方が到着します。
4. しかし宛先が「未変更社員」の場合、そのMBOXは依然として旧MSV1～3に存在します。新MSVが下線②のように「LDAPの情報を用いてメールルーティング」を行わなければ、これらのメールは正しく旧MSVへ転送されず、配送不能になります。
5. よって、下線②が必要な理由は「送信元：メール送受信サーバの変更を実施済みの社員 又は 社外／宛先：未変更社員」という組合せのメールが移行期間中に発生するからです。

誤りやすいポイント

• 「社外メールは旧MSVが受け取る」と思い込み、新MSVでのルーティングが不要だと判断してしまう。実際にはMGWからの転送先はVIP1（新MSV側）に変更済みです。
• 送信元として「変更済み社員」のみを想定し、社外からのメールを忘れる。社外メールもLDAPルーティングの対象になります。
• 宛先を「全社員」と広く考えてしまい、解答が曖昧になる。必要なのは「未変更社員」宛てのメールと限定されています。

FAQ

解答の論理構成

1. MGWが参照する転送先
   　表2「開始工程」で「MGW1、2の、社内宛てメールの転送先IPアドレスを、VIP1に変更する。」とあるとおり、社外→社内のメールは必ずMGW ➡ VIP1（＝VRRPg1の仮想IP）に届きます。VIP1は「新MSV1, 2」のVRRPアドレスなので、受信側の“入り口”は必ず新MSVです。
2. LDAPに基づくメールルーティング
   　移行工程中は「②新MSVも、旧MSVと同様に、LDAPの情報を用いてメールルーティングを行う」とあり、宛先に応じて新MSVが転送可です。さらに「各社員の申告に基づいて、③LDAPの情報を変更する」とあるため、未変更社員のエントリは旧MSVのままです。したがって、新MSVはLDAPで旧MSVを見付けてメールを転送します。
   　→（ア）の経路は「送信元のメールサーバ → MGW → 新MSV → 旧MSV」。
3. 未変更社員の送信動作
   　移行工程ではPC設定を「旧MSVの使用も継続できるように、旧MSVの設定は残す」としており、未変更社員は従来どおり旧MSVをSMTPサーバとして使います。よって、
   　（イ）の経路は「送信元PC → 旧MSV → MGW → 宛先のメールサーバ」となります。

誤りやすいポイント

• 「MGWがVIP1に転送＝常に新MSV1」と早合点しがちですが、VRRPのため新MSV2がアクティブでもVIP1は生きています。重要なのは“必ず新MSV経由”になる点です。
• LDAP変更の有無とPC設定変更の有無を混同しやすいです。未変更社員はLDAPもPCも旧MSV指定のままと整理しましょう。
• 「MBOXは新MSV側に移す」と読んで旧MSV行きメールは存在しないと勘違いするケースがありますが、移行工程では旧MSVにもメールが残ります。

FAQ

解答の論理構成

• 【問題文】には「メールアドレスとそのMBOXを収容するMSVとの対応を、LDAPに登録している」とあります。すなわち、LDAPは“宛先メールアドレス ⇒ どのMSVが保管先か”という対応表の役割を担っています。
• 移行工程では「②新MSVも、旧MSVと同様に、LDAPの情報を用いてメールルーティングを行う」と明記されており、メール配信経路の判定は引き続きLDAPに依存します。
• さらに表2の説明で「各社員の申告に基づいて、③LDAPの情報を変更する」とあり、申請者（＝メールソフト設定を済ませた社員）の情報だけを書き換える運用が示されています。
• 以上より、変更されるのはLDAPに保存されている「メールアドレス → 収容MSV」の対応先であり、旧MSVから新MSVへ“参照先サーバ”を差し替えることだと論理的に導けます。

誤りやすいポイント

• 「MBOXの物理位置を示す属性そのものを編集する」と誤解し、サーバ名変更の意図を読み落とす。
• VRRPやDNSラウンドロビンの話題と混同し、IPアドレスを書き換えると答えてしまう。
• LDAPで保持しているのは“社員アカウント情報全般”と広く捉え過ぎて、メールルーティング以外の情報まで変更対象と述べてしまう。

FAQ