はじめに
Willow Commons には、すでに正常に動くコミュニティサイトがあります。移転する前に、クライアントが実際にどのアドレスを使っているか調べましょう。保存された DNS レコード、キャッシュ内の応答、Web サイトの応答は、それぞれアクセス経路の異なる部分を表しています。
まず通常のサイトを利用し、実際の権威サーバーと独立したキャッシュリゾルバーを比較してから、別の練習用の名前を変更します。このユニットでは、コミュニティが使う正式なサイト名は変更しません。2 つの HTTP バックエンドと DNS サービスは、1 台の VM のカーネルを共有する、分離された Linux ネットワーク名前空間に用意されています。
ターミナルへのコマンド入力、パスの識別、タブの切り替えに慣れていることを前提とします。必要な DNS コマンドと小さな設定変更は、このラボで説明します。公開ドメインのアカウントや BIND の管理経験は不要です。読む時間と一般的なミスへの対応を含め、約 40 分を見込んでください。これは作者による目安です。
稼働中のサイトに名前でアクセスする
このステップでは、コミュニティの既存サイトを読み、実際のイベント案内を保存します。Community Preview を開き、Warm Client を選択してください。Willow Commons のページ、3 つの集まり、old location のラベルが表示されるはずです。Download the programme を選び、ダウンロードしたテキストを開きます。この場所のラベルはバックエンドの識別情報であり、成功を演出するアニメーションではありません。
上部付近の場所のラベルを確認し、3 つの集まりの下にある Download the programme を使ってください。画像のページは、元のバックエンドから返された実際の応答です。
プレビューは、選択したコース用クライアントから実際の DNS 検索と HTTP リクエストを行います。外側のプラットフォーム URL はブラウザー用ゲートウェイであり、手元のコンピューターがコースの DNS を使っていることを意味しません。ブラウザーを更新すると新しいリクエストが送られますが、コースのリゾルバーキャッシュは消去されません。今は Fresh Client を使わないでください。
Warm Client ターミナルに切り替えます。このクライアントは独自のリゾルバー設定を持ち、/home/labex/project/site-move/warm で開始します。pwd は現在のディレクトリを表示します。
pwd
DNS（Domain Name System）は、名前をアドレスに対応付けます。A レコードは、名前を IPv4 アドレスに対応付けるレコードです。その後、HTTP がそのアドレスとポートを使ってコンテンツを要求します。ここでの名前は site.community.test です。8081 は HTTP ポートであり、DNS レコードの値ではありません。.test はテスト用に予約された接尾辞で、公開されたコミュニティ用ドメインではありません。
curl は HTTP リクエストを行います。--noproxy '*' は、このリクエストでプロキシを一切使わない指定です。引用符により、アスタリスクは文字どおりに扱われます。-f は HTTP エラーを失敗として扱い、-s は進捗表示を隠し、-S はエラー表示を残します。--max-time 5 はリクエストを 5 秒に制限します。
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Willow Commons と old location を含む HTML が返るはずです。ターミナルはソーステキストを表示し、ブラウザーは同じページを描画します。次に、実際のテキストリソースをダウンロードします。-o programme.txt は、このクライアントの現在のディレクトリに応答を保存します。
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat は保存したファイルを表示します。
cat programme.txt
3 つの集まりすべて、段差のない入口の情報、Service location: old が含まれているはずです。ファイルが存在することや HTTP ステータスだけでは、内容が正しいとは確認できません。
curl が Could not resolve host を報告したら、名前の綴りを確認してください。Failed to connect は HTTP 接続を確立できなかったことを示します。これは、サーバーは応答したもののパスが存在しない HTTP 404 とは異なります。入力ミスを修正し、示した URL で再試行してください。プラットフォームの DNS、/etc/hosts、コースのリゾルバーファイルは変更しないでください。別のターミナルを開いた場合は、実際の Warm Client タブを使い、保存する前に cd /home/labex/project/site-move/warm を実行します。ファイルと作業ディレクトリは各クライアントに属し、ブラウザーでのダウンロードはブラウザー側に保存されます。
権威サーバーとキャッシュを比較する
このステップでは、元のレコードと一時的なキャッシュのコピーを区別します。Warm Client に留まってください。権威サーバーは community.test を管理し、そのアドレスは 10.94.0.2 です。クライアントのキャッシュリゾルバーは、クライアント内部のループバックアドレス 127.0.0.1 で待ち受けます。もう一方のクライアントには、別のリゾルバーとキャッシュがあります。
dig は DNS に問い合わせるコマンドです。@10.94.0.2 はサーバーを明示的に選択します。A は IPv4 アドレスを要求します。+noall は通常の dig の各セクションを隠し、+answer は回答行を表示します。
dig @10.94.0.2 site.community.test A +noall +answer
次のような形式の行が返るはずです。
site.community.test. 120 IN A 10.94.0.10
各列は名前、TTL、クラス、タイプ、アドレスです。TTL（Time to Live）は、応答をキャッシュに保持できる秒数です。IN は Internet クラスを意味します。末尾のドットは完全な DNS 名を示します。スペースやタブの数は異なることがあります。
今度はコース用クライアントのリゾルバーに問い合わせます。
dig @127.0.0.1 site.community.test A +noall +answer
アドレスは引き続き 10.94.0.10 のはずですが、先のリクエストでキャッシュが作られたため、TTL は小さくなっていることがあります。sleep 5 は DNS を変更せず、実際に 5 秒待ちます。
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
通常は残りの TTL が減少します。以前のコピーが期限切れになった場合、リゾルバーは権威サーバーに再度問い合わせ、TTL が 120 に近い値に戻ります。ラボを読んでいる間に、この時間をすべて使うこともあります。これは通常の期限切れであり、キャッシュの故障ではありません。環境準備直後の特定の観察時間を捉える必要はありません。
次の編集には、別の名前を使います。同じ古いバックエンドを指しますが、コミュニティの正式なサイト名ではありません。
dig @127.0.0.1 practice.community.test A +noall +answer
名前、アドレス、残りの TTL を確認しておきます。検索が成功しても、Web サイトに到達できる証明にはなりません。ステップ 1 では、そのために別途 HTTP リクエストを実行しました。このステップのチェックを実行し、次のステップを読んでから、短い変更と比較の操作を始めてください。
練習用レコードを変更してキャッシュの期限切れを待つ
このステップでは、小さなレコード変更を検証して権威サーバーに読み込み、TTL を短くしても既存のキャッシュの寿命は短くならない理由を確認します。変更できるのは practice と、community.zone 内の必要な SOA シリアル番号だけです。正式な site、keep、ネームサーバー、両方の Web サイトは維持してください。
まず以下の編集手順を読みます。その後、Warm Client で、タブを切り替える直前に練習用の名前を再度検索します。
dig @127.0.0.1 practice.community.test A +noall +answer
残りが数秒しかない場合は、その時間が過ぎるのを待ち、権威サーバーがまだ元のレコードを保持している間に再度検索します。これは実際の DNS リクエストで観察時間を新たに確保する操作で、キャッシュの消去ではありません。新しいコピーは最大 120 秒保持されます。自分のペースで進め、観察時間を逃したら後述の復旧方法を使ってください。
DNS Desk に切り替えます。ディレクトリは /home/labex/project/site-move です。ファイルを読みます。
cat community.zone
ゾーンは、DNS のある範囲について権威サーバーが保持するデータです。$TTL 120 は既定の有効期間を指定します。practice 120 IN A 10.94.0.10 は、練習用の名前の有効期間とアドレスを明示します。SOA（Start of Authority）には、シリアルと呼ぶバージョン番号があります。変更を公開するときはこの番号を増やし、その他の SOA の値は保ちます。DNS の有効期間と SOA のタイマーは用途が異なります。ここで @ はゾーンの起点 community.test. を表します。NS は権威サーバーを指定し、ns の A レコードはそのサーバーのアドレスを示します。括弧は SOA の各フィールドを 1 つのレコードにまとめます。既存の更新、再試行、期限切れ、ネガティブキャッシュの値はゾーン管理の設定なので、変更しないでください。これらは練習用 A レコードの TTL ではありません。
次のヒアドキュメントは、小さなゾーン全体を書き込みます。> はファイルを置き換えます。引用符付きの 'ZONE' は、$TTL をシェル変数として展開せず、文字どおりに保持します。最後の ZONE は行頭に置く必要があります。ブロック全体をコピーしてください。
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
変わったのは、練習用のアドレスと有効期間、およびシリアル番号だけです。named-checkzone は、保存したゾーン全体を検証しますが、読み込みは行いません。第 1 引数はゾーン名、第 2 引数はファイルです。
named-checkzone community.test community.zone
loaded serial 2 に続いて OK が表示されるはずです。これはファイルの検証結果であり、実行中の権威サーバーが読み込んだ証拠ではありません。構文が不正なら、ファイルを読み、完全なブロックを復元してから再確認します。保存ファイルが不正でも、有効な再読み込みが行われるまでは、以前の稼働中ゾーンが利用可能なままです。
sudo は、この 1 つの管理コマンドを実行します。用意された範囲の限定されたヘルパーは、コースの権威サーバー内部で BIND の実際の rndc reload community.test を呼び出します。どちらのキャッシュも再起動しません。
sudo /opt/labex/site-move/reload-zone
zone reload queued が表示されるはずです。実行中の権威サーバーを検索し、実際に読み込まれたデータを確かめます。作業台自体にはコース用の既定リゾルバーがないので、この診断では権威サーバーのネットワーク名前空間に明示的に入ります。ip netns exec site-authority は、直後のコマンドだけをそのコースネットワーク内で実行します。
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
45 IN A 10.94.0.20 が返るはずです。Warm Client に切り替え、そのキャッシュを検索します。
dig @127.0.0.1 practice.community.test A +noall +answer
元の有効期間が残っている間は、45 秒より多く残っていても、引き続き 10.94.0.10 が返ることがあります。新しい 45 秒の TTL は新しいコピーに適用され、古いキャッシュ応答を書き換えません。クライアントが正当に異なる結果を得る間も、両方のバックエンドは稼働し続けます。
今観察した残りの TTL に 1 秒を加えた時間を待ち、再度検索します。たとえば 37 秒と表示された場合、そのコピーには sleep 38 で十分です。次の余裕を持った待機は、正確な値を控えていなくても、この練習の元の最大値 120 秒全体をカバーします。
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
今度は 10.94.0.20 と、45 以下の残り TTL が返るはずです。実際の行を読んでください。タイマーが終了しただけでは何も証明できません。同じクライアントから、名前を使って HTTP リクエストを行います。
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Service location: new と完全なイベント案内が返るはずです。正式な site.community.test は、引き続き古い場所のコンテンツを提供します。
差を見逃した場合： 完了した結果はそのまま有効です。観察を繰り返すときは practice だけを使います。DNS Desk でその行を practice 120 IN A 10.94.0.10 に戻し、nano community.zone で現在の SOA シリアル番号を増やします。nano はテキストエディターです。矢印キーで移動し、その行とシリアルだけを編集し、Ctrl+O、Enter で保存して、Ctrl+X で終了します。上と同じコマンドで検証し、再読み込みします。練習クライアントで現在観察されている TTL が自然に切れるのを待ち、検索して最大 120 秒の古いアドレスを取得します。次に practice だけを新アドレスと 45 秒に戻し、さらに大きいシリアルで検証、再読み込みを行い、すぐに比較します。最後は自然な期限切れと、新サイトへの実際のリクエストで終えます。観察時間を繰り返すために、正式サイトのリセット、リゾルバーの再起動、Web コンテンツの置き換えを行わないでください。
パスを入力し間違えたら、DNS Desk で pwd と cd /home/labex/project/site-move を使い、ファイルを読み直します。構文エラーと内容の誤りは別の問題です。ファイルを検証し、実行中の権威サーバー、キャッシュの順に確認してから HTTP を要求します。練習クライアントが新アドレスを解決するようになったら、最終チェックを実行してください。
まとめ
稼働するサイトに名前でアクセスし、完全なイベント案内を保存して、権威データ、キャッシュされた DNS 応答、HTTP コンテンツを区別しました。限定された練習用の変更を検証し、TTL を下げても既存のキャッシュの寿命は短くならないことを確認しました。コミュニティの正式サイトと古いバックエンドは引き続き利用できます。次のユニットでは、この知識を段階的なアドレス移転に応用します。
