第10〜12章
DNSソフトウェア
BINDが主流だったがいろいろ出てきた
とはいえいまだに多くのUNIX系のOSに標準搭載なので一般的
ゾーン転送によるデータ不整合のリスク
本来は親ゾーンと子ゾーンで同じ内容のNSリソースレコードを設定する必要があるが、不整合が起こってしまうと委任に関するトラブルの原因になる
DNSはUDPとTCPの何を使用しても良いことになっている
UDP53番ポートに対してもTCP53番ポートに対してもアクセスを許可する必要がある
また、プライマリサーバーからセカンダリサーバーへのポート53番宛の通信の許可も必要
ゾーン転送でDNS NOTIFYを送信するため
国際化ドメイン名について
インターネットが各国に広まるにつれて各国語で表記された名前のドメイン名の需要が高まった
国際化ドメイン名(IDN)の標準化が開始された
変換前の国際化ドメイン名=U-label ドメイン名例
従来のドメイン名の表記に変換したもの=A-label xn-eckwd4c7cu47r2wf
xn-は国際化ドメイン名のAーlabelであることを表すプレフィックス
ハイフンの後ろはPunycodeという方式で変換した文字列
権威サーバー(NSリソースレコード)そのものの移行とゾーンデータの移行を別々のタイミングで行う
移行元と移行先の双方の権威サーバーを動作させる並行運用期間を設定する
データの移行の際はキャッシュを考慮する必要がある
具体的にはTTLの値を調節する必要がある
もし親のNSリソースレコードと子のNSリソースレコードが異なった場合、フルリゾルバーの挙動は一定していない
フルリゾルバーのキャッシュ状況はアクセスタイミングにより異なる
利用者のスタブリゾルバーから受け取った名前解決要求の内容とタイミングに依存する
レジストリが変更申請を受け付けてから変更を実施するまでの時間がレジストリによって異なる
本来あるべき引越し手順
移行先サーバーの用意
権威サーバー、メールサーバー、Webサーバー
移行先の権威サーバーには移行先のゾーンデータを設定
ゾーンデータ=移行先のメールサーバーやWebサーバーを指定した(向いた) MX/A/AAAAリソースレコードのこと
TTLを短くしておく(移行元へ切り戻しが必要になった時にすぐ戻せるから)
現在設定されている移行元のMX/A/AAAAリソースレコードのTTL値の短縮
これを短く設定するほど並行運用期間が短くなる
TTLの設定の後、元のTTLの時間が経過するとキャッシュが消える
移行元の権威サーバー、メールサーバー、WebサーバーなどMX/A/AAAAリソースレコードの設定を移行先のものに変更
https://gyazo.com/abb002dff14da720f2fde1f03fae478a
移行元の権威サーバーに設定されていた古いMX/A/AAAAリソースレコードのキャッシュがインターネット上のフルリゾルバーから消えた時点でメールサーバー、Webサーバーの移行が完了する
メールは古いリソースレコードが残っている間は両方に届き、古いリソースレコードのキャッシュが消えたら完全に移行先のみの運用になる
移行元のメールサーバーをMXリソースレコードの変更時に停止すると、配信は一時停止するが、移行元の理sースレコードのキャッシュが消えた時点で移行先のメールサーバーに自動的に再配送される
並行運用期間中はWebサーバーのアクセスも移行元・移行先の双方に到達する
並行運用期間中はWebアクセスのセッション管理やクッキーの取り扱いなどの対応に注意が必要
ゾーンデータの移行後に権威サーバーを移行する
NSリソースレコードとグループレコードの設定変更
NSリソースレコードは親子の双方を変更する
移行元の子ゾーンのNSリソースレコードを移行先のものに変更
親ゾーンの委任情報の変更を申請
https://gyazo.com/08e87799e1d68d0d8d0631984e9482c2
親ゾーンのNSリソースレコードのTTL値を事前に確認しておくといい(TLDによって異なる)
並行運用期間として下記の時間を設定する
子ゾーンの古いNSリソースレコードのキャッシュがフルリゾルバーから消えるまであの時間
親ゾーンの古いNSリソースレコードのキャッシュがフルリゾルバーから消えるまでの時間
並行運用期間が終わったら移行元サーバーを停止(解約)
MX/A/AAAAリソースレコードのTTL値の復旧
意図的に短くしているので元の設定に戻しておく
権威サーバーと他のサーバーの移行を同時に行う場合
https://gyazo.com/dee97197190bcf85c6411ad926ee2ccd
DNSの浸透待ち、や反映待ち、などの言葉は不適切