外部DNSはDMZの公開ドメインを管理する。内部DNSは社内ドメインを管理し、社外名の問い合わせはISPのリゾルバへ転送する。内部DNSはDHCP機能も持つ。

問題

解説：社内名を解決でき、社外名も転送できる内部DNSを利用する。外部向け権威サーバを、そのまま社内PCの問い合わせ先にする構成ではない。

旧APサーバと移行先を並行稼働させ、DNSレコードの変更で切り替える。事前にDNSのTTLを短くする。

問題

解説：旧IPのキャッシュが残る期間を短くすることが目的である。既に長いTTLで保持された情報を、その場で強制削除する操作ではない。

EDNSによってUDPで送受信できるDNSメッセージサイズを拡張できる。それでも合意した最大サイズを超える場合や、EDNS非対応の相手と512バイトを超える応答をやり取りする場合がある。

問題

解説：IPv6アドレスを問い合わせることと、DNS自身がどのIP・トランスポートを使うかは別の話である。原問ではIPv4のDNS通信でもAAAAレコードを取得できるとしている。サイズ制約への対応としてUDPからTCPへ切り替える。

DNS応答には次の内容が含まれている。saas.example.com.のCNAMEはdual-saas.example.net.である。後者のAAAAレコードは2001:db8:xxxx::10と2001:db8:xxxx::20である。

権威セクションには、example.net.のNSとしてns1.example.net.とns2.example.net.が示されている。追加セクションには、その二台のDNSサーバのIPv4アドレスがある。xxxxは原問の仮表記を維持している。

問題

解説：CNAMEは別名から正規名への対応を示す。実際の接続先アドレスはAAAAレコードから読む。NSレコードは名前情報を管理するサーバを示すので、SaaSの接続先と混同しない。

DNSのSRVレコードには、Kerberosサービスが稼働するホスト名などを登録できる。PCはサービス名を問い合わせて認証先を発見する。

問題

解説：サービス名から接続先を自動発見しないため、接続対象をPCへ明示する必要がある。

KerberosサービスのSRVレコードにはTTLとして43200が設定されている。TTLの単位は秒である。

問題

解説：43,200秒÷60＝720分となる。TTLの数値をそのまま分として扱わない。

既存のSRVレコードは同じPriorityで、DS1のWeightを2、DS2を1としている。変更後はSRVのTargetを共通名DSにまとめ、Aレコード側のDNSラウンドロビンで同じ利用比率を表す。

DS1のIPアドレスをadd1、DS2をadd2と表す。原問はAレコードの記載数で利用比率を表すモデルを用いている。

問題

解説：公式解答は、元のWeight 2対1をAレコードの記載数2対1へ対応付けている。この教材では原問のモデルを保持しており、個別DNS実装での重複レコードの扱いを検証したものではない。

既存Webサーバは静的コンテンツを返し、動的処理の要求はAPサーバへ中継する。DNSサーバは、自社ドメインの公開情報の管理と、内部サーバから依頼される外部ドメインの名前解決を担う。

HTTP/2は一つの接続上に複数の仮想的な通信チャネルを設ける。要求には、メソッド・スキーム・パスを示す疑似ヘッダを用いる。HTTPSでのHTTPバージョン選択にはALPNを利用する。

問題

解説：権威DNSは管理対象のゾーンの情報に基づいて応答する。キャッシュDNSは利用者の依頼に応じて名前解決する。両者は同じ装置に実装されていても役割が異なる。

HTTP/2ではストリームを識別して複数の要求を扱う。「:method」は要求メソッドを示す。ALPNはTLS接続時にアプリケーションプロトコルを選択する仕組みである。

出荷時に店舗ルータへ管理コントローラの接続先を設定する。管理コントローラは将来IPアドレスが変わる可能性がある。

問題

解説：DNSの対応先を変更すれば、ルータ側に設定した名前を維持できる。全国の店舗ルータを一台ずつ書き換える負担を避けられる。

店舗ルータは管理コントローラのREST APIを利用し、自身のシリアル番号と外部接続ポートのIPアドレスを登録する。

問題

解説：REST APIという呼び出し方式と、通信で用いるプロトコルを区別する。原問の解答はHTTPまたはHTTPSである。

プロキシサーバBは192.168.1.145、プロキシサーバCは192.168.2.145を使用する。利用者が指定するproxy.a-sha.co.jpに、両方のAレコードを登録して、平常時から両サーバを利用する。

問題

解説：同じ名前に複数のアドレスを対応付ける。原問では障害時にDNSゾーンを書き換える運用も組み合わせるため、DNSへの登録だけで障害検知まで完了するわけではない。

平常時はproxy.a-sha.co.jpを192.168.1.145のプロキシBへ対応付ける。待機系のプロキシCは192.168.2.145である。Bの異常を検知したため、利用者が指定する名前をCへ切り替える。

問題

解説：利用者が使う名前を変えずに、名前解決の結果を待機系のアドレスへ変更する。利用者が直接指定していない個別サーバ名だけを書き換えても、切替にはならない。

プロキシ障害時は、利用者が指定するホスト名のAレコードを書き換える。平常時から、このレコードのTTLを小さく設定する。

問題

解説：権威側のレコードを変更しても、保持中の古いキャッシュは直ちに消えない。保持時間を短くして、新しいアドレスで再解決されるまでの待ち時間を抑える。

障害時にプロキシを自動で切り替える方法を検討している。DNSゾーンの変更とは別に、利用者側で実行されるプロキシの自動設定機能も利用できる。

問題

解説：自動設定は利用側の対応に依存する。すべてのアプリケーションが同じ仕組みを使うとは限らないため、原問ではDNSによる切替と併用する。

社内メールサーバは二台の中継サーバへ送信を分散する。社内DNSには、mail.y-sha.lanのAレコードとして192.168.0.1と192.168.0.2が登録されている。個別名y-mail1.y-sha.lanとy-mail2.y-sha.lanはそれぞれ一方だけを示す。

問題

解説：二つのIPアドレスが同じ名前に登録されているFQDNを指定する。個別名を固定指定すると、DNSラウンドロビンによる二台への分散を利用できない。

y-sha.comのMXはy-mail1.y-sha.comに20、y-mail2.y-sha.comに1を設定する。別の確認方法では、送信元メールサーバのIPアドレスからFQDNを取得する。

問題

解説：MXはPreferenceの数値が小さい方を優先するため、1のy-mail2が選ばれる。逆引きはIPアドレスを起点とする名前解決であり、Aレコードによる正引きとは方向が逆である。

DNSサーバはexample.jpとy-sha.example.lanを管理する。DNSサーバの内部IPは192.168.1.1、メールサーバの内部IPは192.168.1.3である。

FWの静的NATは、100.α.β.1のTCP/UDPポート53を192.168.1.1へ、100.α.β.3のTCPポート25を192.168.1.3へ変換する。α・βは原問の伏字である。

問題

解説：外部利用者はNATの外側のアドレスへ接続する。社内側は内部アドレスへ直接接続するため、同じサーバでも用途別の名前に対応するアドレスが異なる。

PCにはプロキシサーバのFQDNを設定している。社内の業務サーバと営業支援サーバには、ブラウザから直接接続する必要がある。

問題

解説：プロキシの設定を全面的に無効化するのではなく、社内の対象だけを直接接続へ切り替える。

DNS通信を許可するFWルールには、TCPポート53が記載されている。通常の名前解決で使うもう一つのトランスポートも許可する必要がある。

問題

解説：DNSはUDPとTCPの両方を使用する。TCPの許可だけでは、UDPを利用する問い合わせを通せない。

HTTP/1.1では、前の応答を待たずに複数の要求を送るパイプライン処理を利用できる。サーバは要求ごとに処理時間が異なる。

問題

解説：受信順序で要求と応答を対応付けるため、後の要求の処理が先に終わっても、その応答だけを先に返すことはできない。

HTTP/1.1とHTTP/2のどちらを利用する場合も、URLのスキームはhttpsである。URLだけでは利用するHTTPバージョンを区別できない。

問題

解説：同じHTTPSの接続先でも、クライアントとサーバが利用できるプロトコルは異なり得る。ALPNで双方が利用できるプロトコルを選ぶ。

クライアントはTLS接続の開始時にALPN情報をサーバへ送る。サーバは、その情報から使用するアプリケーションプロトコルを選択する。

問題

解説：提示するのは対応可能なプロトコルの候補である。これによって、サーバはクライアントが利用できないプロトコルを選ぶことを避けられる。

HTTP/1.1による複数画像の取得を、先行処理が終わるまで後続処理を進められない直列処理として考える。先頭処理に時間がかかると、全体の完了も遅くなる。

問題

解説：注目するのは、個々の画像の大きさではなく処理間の待ち関係である。本問はHTTPレイヤーとTCPレイヤーのHoLを区別している。HTTP/2でHTTPの多重化が可能になっても、TCP側の待ち関係までなくなるとは述べていない。

HTTP/1.1では、PCからの要求とサーバからの応答を繰り返す。HTTP/2では一つのTCPコネクション内で複数ストリームを扱い、各ストリームを識別する値を付ける。

問題

解説：一つのTCPコネクションを複数の論理的な通信に共有させるため、ストリームごとの識別が必要となる。本問では、HTTP/1.1で複数TCPコネクションを使う場合と比較して、NAPTエントリー数を抑える関係も示している。

DMZのWebサーバはプライベートIPアドレスを使う。PACでは宛先がプライベートIPアドレス、ループバック、localhost、または社内ドメインa-sha.jpの場合、DIRECTを返す。

問題

解説：DIRECTはプロキシを使わず、宛先へ直接接続する指示である。DMZのWebサーバはプライベートIPアドレスという条件に一致する。

PACは社内宛てにはDIRECT、image.cdn.exampleまたは*.c-saas.example宛てには大阪UTMのproxy.osaka.a-sha.jp:8080を返す。どちらにも該当しない場合はproxy.a-sha.jp:8080を返す。

問題

解説：www.example.comは社内宛てでも指定SaaS宛てでもない。最後の既定処理に到達するため、本社のプロキシが選ばれる。

SaaSへのアクセスは各支社のUTMプロキシから直接インターネットへ出す。大阪支社はproxy.osaka.a-sha.jpを使い、別の支社では別のFQDNを使う。PACには選択先のFQDNを記載する。

問題

解説：SaaSの宛先条件が共通でも、条件に一致した際の返却先が支社ごとに異なる。同じ大阪向け設定を他支社へ配ると、意図した現地の出口を選べない。

WPADはネットワークの設定情報や名前解決を使い、PACファイルの場所を検出する。検出後はWebサーバからファイルを取得する。自動検出を無効にする場合は、PACの場所をPCへ直接設定する。

問題

解説：場所を見つける処理と、ファイル本体を取得する処理を分ける。DHCPやDNSは検出を助けるものであり、PACの本体を取得するHTTPとは役割が異なる。

クラウドの仮想LBは、利用者側とはHTTP/2で通信する。既存のWebサーバとAPサーバはHTTP/1.1を使用する。仮想LBはURLに応じて転送先を振り分ける。

問題

解説：URLの判定とHTTPバージョンの変換には、アプリケーション層の情報を解釈する必要がある。IPアドレスやポートを基に転送するネットワークモードだけでは、この要件を満たさない。

AP0のFQDNはap0.u-sha.com、AP1はap1.u-sha.comである。両方とも共有リバースプロキシへHTTP接続する。プロキシはHTTPヘッダからAPを識別する。

問題

解説：宛先IPとポートが共通でも、HTTP要求のHostから指定されたホスト名を読み取れる。APごとのFQDNを振り分け条件にする。

利用者のECサイトURLと、既存のDNS応答値は変更しない。既存ECサーバには新しいホスト名とIPを付け、従来のサービス用内部IPは新設機器で受け付ける。

問題

解説：利用者に見せるサービスの入口をLBへ移す。実サーバを追加しても、利用者が指定する名前やサービスIPを変えずに済む。

最終案ではECサーバのデフォルトゲートウェイをFWzのままにし、LBでソースNATする。ECサーバはアクセス元IPをログに記録するため、LBはHTTPヘッダにX-Forwarded-Forを追加する。

問題

解説：IPヘッダの送信元はLBへ変わる。LBが元のクライアントIPをHTTPヘッダで伝えることで、アプリケーション側の記録に利用できる。

LBは同一の購買操作を同じECサーバへ転送したい。アクセス元IPとTCP送信元ポートの組を識別子にすると、TCP接続の切断・再接続時に同じセッションへ対応付けられないことがある。

問題

解説：購買操作のセッションはTCP接続より長く続く場合がある。接続ごとに変わる値だけでは、アプリケーションの継続した操作を識別できない。

ECサーバは最初のアクセスでセッションIDを生成し、応答のCookieに入れる。LBはセッションIDと振分け先サーバを管理表に登録し、以降の要求を同じサーバへ送る。

問題

解説：新しいセッションIDを受けた時点で、応答元サーバとの対応を登録する。登録済みのIDを利用する後続要求は、同じサーバへ転送できる。

CoAPはUDPを利用する。UDPでは到着順序や一度だけの配送は保証されない。CoAPはACKを待たずに次のCONを送ることができる。再送間隔は再送回数に応じて長くする。

問題

解説：UDPの保証しない性質を、CoAPのメッセージID・ACK・再送制御で補う。アプリケーションの要求と応答の対応付けには、これらとは別にトークンを用いる。

端末はGET /data1をCONで送り、メッセージIDを0xbc90、トークンを0x71とした。サーバはまず空のACKを返した。その後、データZを含むCONをメッセージID0xcdf2、トークン0x71で送った。ほかの応答のトークンは0x82と0x90である。

問題

解説：空のACKは要求の受領だけを知らせる。後から送る分離応答は、新しいメッセージIDを使用してもよい。要求と応答の組合せはトークンで確認する。

端末はGET /data2をメッセージID0xab20、トークン0x82で送った。サーバではデータXを直ちに準備できる。応答候補にはID0xab20・Token0x82・データXのACKと、別のIDやトークンを持つメッセージがある。

問題

解説：応答をすぐ返せる場合は、ACKに応答コードとデータを載せられる。原問では要求のメッセージIDとトークンの両方に対応するACKを選ぶ。

端末はID0xde10、Token0x90、データYを含むACKを受け取って処理した。その後、同じ内容とIDのACKを再び受信した。

問題

解説：この設問では要求・応答の組合せではなく、同じメッセージの重複を判断する。したがって着目するのはトークンではなくメッセージIDである。

同じ測定データを送る方式としてCoAPとHTTP/1.1を比較する。原問ではHTTP/1.1を利用した方が、やり取りするIPパケット数が多くなる。

問題

解説：CoAPはUDPを使用する。比較対象のHTTP/1.1では、データの送信以外にTCP接続の確立と切断が必要となる。原問の通信条件における比較であり、あらゆる接続再利用条件を同一視しない。

既存構成では、同一拠点内の電話はPBXを使う。外線は公衆電話網を使う。拠点間はPBXに接続したIPゲートウェイから広域イーサネットへ接続する。

問題

解説：IPゲートウェイを経由するのは拠点間の内線である。電話を使う全ての通信が、この既存構成でIP化されているわけではない。

複数の専用APが同じTCPポート番号を使用する。HTTPのHostヘッダのような共通のアプリケーション識別情報は利用できない。負荷分散装置からAPを区別したい。

問題

解説：ポート番号だけでは区別できないため、接続先IPも使ってAPの入口を分ける。HTTP用の識別方法を独自プロトコルへそのまま適用しない。