ネットワークスペシャリスト 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