設問１
（１）a:ゾーン転送 b:SMTP
ゾーン転送：
DNSサーバ間で情報を同期するための仕組みをゾーン転送という。主にプライマリDNSとセカンダリDNS間で実施される。通常のDNSはUDPが使われるがゾーン転送は大容量＆信頼性が求められるためTCPが使われる。
＊UDPでもEDNS0という拡張機能を使うと512B以上を扱えるが信頼性を考慮するとTCPが使われる。
b.SMTP :
MGWとMSVでのやり取りはメール転送である。そして、メール転送で使われるプロトコルはSMTP。なので、答えはSMTPになる。
| 項番 | 送信元 | 宛先 | プロトコル |
| 1 | MGW1, 2 | MSV1 | b:SMTP |
| 2 | MSV1〜3 | MGW1, 2 | b:SMTP |
| 3 | DNS3 | c:DNS1 | DNS プロトコル |
| 4 | DNS1 | DNS3 | DNS プロトコル |
▼ゾーン転送の流れ
１．notifyやrefreshを契機に始動
notify:プライマリDNSに変更があった際に、プライマリDNSがセカンダリDNSに「俺、変更したよぉ」と通知するメッセージのこと
refresh:SOAレコード内から得られる情報で、「プライマリへの確認作業のインターバルはこの時間で！」と教えてくれる値。この時間が経過したらセカンダリはプライマリにSOAレコードの取得を試みる
２．SOAレコードの取得
１を契機にプライマリDNSにSOAレコードの取得依頼を送る。
＊この通信はUDP53が使われる。
３．シリアル番号の確認
①セカンダリDNSがSOAレコードを取得すると、レコード内のシリアル番号の値を確認する。
②既に持っているシリアル番号よりも大きい場合→ゾーン転送が必要
既に持っているシリアル番号よりも小さい場合→ゾーン転送が不要
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2026071601 ; Serial (シリアル番号)
10800 ; Refresh (リフレッシュ間隔)
3600 ; Retry (リトライ間隔)
604800 ; Expire (有効期限)
86400 ; Minimum TTL (ネガティブキャッシュTTL)
)４．ゾーン転送要求
ゾーン転送が必要な場合は、「ゾーン情報をください！」とプライマリに依頼
５．ゾーン転送
プライマリがゾーン情報をTCP53番を使いゾーン転送を実施する
（２）c:DNS1
| 項番 | 送信元 | 宛先 | プロトコル |
| 1 | MGW1, 2 | MSV1 | b:SMTP |
| 2 | MSV1〜3 | MGW1, 2 | b:SMTP |
| 3 | DNS3 | c:DNS1 | DNS プロトコル |
| 4 | DNS1 | DNS3 | DNS プロトコル |
Cのプロトコルを確認すると、DNSであることが分かる。で、送信元がDNS3なので、DNS３が実施するDNS通信はDNS1へのゾーン転送に関する通信のみ。そのためDNS1が該当する。
（３）公開ゾーン情報の更新通知
項番４はDNS1→DNS3へのDNSプロトコル通信であることが分かる。なお、本文(p.11 下から8行目)にもある通りnotifyメッセージを送信していることが分かる。つまり、セカンダリへのDNS情報更新通知であることが分かる。
（４）条件：送信元が少数の場合 理由：送信元は、DNSのキャッシュが生存している間、宛先を変えないから
想像してみよう。今回のケースは、本文中より外部からのメール転送はMGW2のみが担当する。つまり、送信元は１つ。そして、宛先をDNSによって名前解決するとそれがキャッシュとして保存される。つまり、MGW2は１つのMSVを使い続けることになる。ほかのMSVはずっと、手が空いている状況だが、キャッシュの時間内は使われることがない。
逆に、送信元が１００台あると、DNS名前解決した結果、すべてのMSV使われるようになる。
以上のことから、送信元が１つだとそもそも１つのMSVしか使われないので負荷分散ができない。そして、その根本的な理由はメール受信ごとに名前解決をするのではなく、キャッシュ機能によって保持されるため１度名前解決をすると、それ以降は使われるMSVが変わることがないから。
逆を言えば、キャッシュがなければ送信元が１つでも、毎回毎回、名前解決するのでラウンドロビン方式でも分散が可能になる。
しかし、処理速度や負荷などを考えると圧倒的にキャッシュを使った方がメリットが大きい。
設問２
（１）d:新MSV1 e:新MSV２
p.13の(3)にもある通り、”新MSV１の故障時にはVRRPによって転送先が切り替わる”とあるので、新MSV１では確実にVRRPが稼働していると推測できる。また、そこからその新MSV１と対をなす存在はMSV2なので、MSV2もVRRPが稼働していることが分かる。
その状況から判断して、dとeにはそれぞれ新MSV1と新MSV２が入る。
設問３
（２）送信元：メール送受信サーバの変更を実施済みの社員 または 社外
宛先：未変更社員
この問題は、新MSVへ届いたメールに対してLDAPを検索しなくてはならない条件を聞いている。通常、新MSVはメールボックスが共有なのでLDAPを使う必要がない。しかし、特定の条件では使う必要が出てくる。それが古いシステムを使っているパターンだ。
もし、未変更社員同士のメールであれば、そもそも新MSVを経由しないのでこの問題の対象外となる。未変更ということは、その社員のメールクライアントには古いホスト名が記されている。それを名前解決すると自ずと旧MSVへルーティングされるので新MSVは経由しない。
これらのことから、送信元が社外または、新MSVのホスト名に変更済みの社員であるパターン。かつ、宛先はメールボックスが移行されていない社員（＝未変更社員）ということになる。
（４）申請者のメールアドレスに対応するメールサーバが、新MSVに変更される
旧メールシステムではメールボックスがMSVごとに分けられていた。適切なメールボックスに格納するためにLDAPを使い適切なMSVに転送していた。そのため、新メールシステムに移行したら、自ずとその設定を新MSVに変更する必要がある。そうしないと、古いメールボックス宛てにメールが格納されつづけてしまうから。
p.11 LDAPサーバ
一言でいうとLDAPサーバとはディレクトリサーバの意。ディレクトリサーバとは組織内のアカウントやデバイスを一元管理するためのサーバ。そしてLDAPはディレクトリサービスにアクセスするための共通ルールのこと。なので、一見するとLDAPサーバと聞くと、ユーザの代わりにLDAP機能を使ってディレクトリサーバにLDAPを使ってアクセスしてくれるサーバなのかなぁとイメージしてしまうけど、IT業界のなかで、LDAPサーバと言ったら十中八九、ディレクトリサーバを指している。
p.11 MGWの転送先をMSV1で固定しているのはなぜ？MSVは3台あるんだから、３台に分散すべきじゃないの？
A.メール転送には重い処理と軽い処理がある。
軽い処理：
届いたメールを右から左へ転送するだけ。
重い処理：
届いたメールをメールボックスすに配置したり、クライアントからの要求によってメールをダウンロードしたりする作業はとても重い。なぜならこれらはハードディスクへアクセス（ディスクI/O）が発生するから。
このようにMSV1に固定されても、MSV1が実施する処理は他のMSVへの転送処理であるため軽い処理で終わる。もちろんMSV1自身に届いたメールは重い処理をするが、それ以外に関しては転送処理が主なので、MSV1の固定でも問題はない。
p.11 MGW2はどうやって転送処理をするの？
A.イメージしてみよう。D社社員へのメールは外部DNS3で名前解決されてMGW2に届く。その後、MGW2はどう処理するの？メールアドレスのドメインで名前解決してもMGW2自身のIPしかわからずループしちゃうんじゃないの？このような疑問が浮かぶだろう。しかし、実際はループせずしっかりと送信できる構成ができている。では、流れを見ていこう！
▼MGW2が内部MSVへ転送するまでの流れ
１．MGW2に外部メールが届く
２．MGW２内のルールを参照
ルール①：外部からＤ社宛てへのメールがきたら、特定のホストへ転送するルールを決めておく。
ルール②：①のホストを名前解決するときにDNSサーバのIPアドレスを登録しておく
ルール③：名前解決をして、適切なホスト（MSV）へ転送する
３．MSVへ届く
p.11 障害が起きたらMGWをどうやって切り替えるの？
A.優先度を使うことによって動的な切り替えが可能になる。
外部からの名前解決の名前解決では２つのレコードを返すようにする。その際に、MGW２をMGW1よりも優先度を高く設定する。これによって、通常時はMGW2が使われるが、障害が起きた際はMGW2に通信できないので、送信側は優先度の低いMGW1を試す。要は送信側のリトライによって動的な切り替えが可能になっているということである。
＊ちなみにMXレコードにおける優先度は、値が小さければ小さいほど優先される。
p.13 メールサーバでVRRPは動作できるの？
p.13では新MSV1と２でVRRPを稼働させる旨の記述がある。ここで疑問が一つ。VRRPってルータなどのファーストホップの冗長化の技術じゃないの？メールサーバでも動かせえるの？答えは、実はメールサーバでも稼働できるんです！Linuxサーバーなどでは 「Keepalived」 という超有名なオープンソースのソフト（デーモン）があり、これを使うことでサーバー自体にVRRPを喋らせる（仮想IPを共有させる）ことが実務でも超一般的に行われている。
では、具体的な流れを見ていこう！
▼メールサーバで実施するVRRPのフロー
１．準備
①新MSV１と２でVRRP設定をする
各MSVは２つのグループに所属し、それぞれに適切なプライオリティを割り当てる
②DNS設定
DNS2にメールサーバのホスト名に対応するAレコードを２つ登録する
＊この際に登録するＩＰアドレスは仮想ＩＰアドレス
２．データ転送
①クライアントのメールソフトにメールサーバのホスト名を登録しておく
②①の名前解決をDNS2に要求する
③仮想ＩＰアドレスが返される。
④ＤＮＳには２つのレコードがあるため、ユーザごとに順番に５０％の確率で別々の仮想ＩＰアドレスのＡレコードが返される。結果的に負荷分散ができる。
３．障害発生時
①マスタのキープアライブが途切れる
②タイムアウトの時間だけ待ったうえで、スタンバイ側が仮想IP/MACを引き継ぐ
③GARPを送信し、配下のスイッチのMACアドレステーブルを更新させる
④当該仮想IP宛ての通信は適切に適切にルーティングされる
４．障害回復
①プリエンプト機能が有効な場合、プライオリティが最も高い機器がマスタに戻る
