クライアントサイトのDNS障害とドメイン失効を防ぐ方法

HTTPのエラーにはステータスコードがあり、サーバー障害はログを残します。DNSに障害が起きると、サイトは名前が示す場所にただ存在しなくなります。訪問者のブラウザにはサイトにアクセスできないというエラーが表示されるか、別の誰かのページが表示されます。

クライアントサイトを抱えるフリーランサーの場合、ほとんどのケースは次の3つの原因で説明できます。

• ドメインの失効：登録済みのカードの有効期限が切れて自動更新に失敗した、または更新のお知らせが誰も読んでいないアドレス（クライアントの古いアドレスなど）に届いていたケースです。
• 移行時のレコードの誤り：Aレコードが古いサーバーを指したままになっている、またはタイプミスでどこも指していないケースです。
• ネームサーバーの変更：誰かがドメインを新しいDNSプロバイダーに移した、またはレジストラの移管でネームサーバーが変わったのに、新しい場所でレコードが作り直されていないケースです。

ドメインが期限切れになると実際に何が起きるか

.com、.net、.orgなどの汎用ドメインでは、ICANNのExpired Registration Recovery Policyが次の流れを定めています。

1. レジストラは登録名義人にリマインダーを送ります。通常はメールで、有効期限の約1か月前と約1週間前、さらに期限切れ後5日以内に少なくとも1回です。クライアントがドメインを登録した場合、リマインダーはクライアントに届きます。
2. 期限切れ後、レジストラはドメインのDNS名前解決の経路を遮断しなければなりません。すると名前は解決されなくなるか、レジストラのランディングページに誘導されます。このページには、登録が期限切れになったことと更新方法を記載する必要があります。つまりサイトは必ずしも「消える」わけではなく、問題なく読み込まれる更新案内ページに置き換わることがあります。
3. 誰も更新せずに登録が削除されると、30日間のRedemption Grace Periodに入り、その間レジストリはDNSの名前解決を無効にします。この段階ではドメインが復旧されるまで誰が問い合わせても失敗し、通常はNXDOMAIN（「そのようなドメインは存在しない」）が返ります。

.sk、.cz、.de、.ukなどの国別ドメインはそれぞれのレジストリの規則に従うため、クライアントごとにドメインのレジストラの規約を確認してください。

実務上のポイントは、ステップ2がステータスコードしか読まないチェックからは正常に動いているサイトに見えることがある点です。

切り分けの手順

クライアントから「サイトが消えた」と言われたら、何かに手を付ける前に以下を実行してください。example.comはクライアントのドメインに置き換えます。

ルートサーバーから回答までの経路と、どこで途切れているかを確認します。

dig +trace example.com

レジストリに登録されているネームサーバーと、想定しているネームサーバーを比較します。

dig +short NS example.com
whois example.com | grep -iE "name ?server|nserver"

有効期限を確認します（フィールド名はレジストリによって異なり、国別レジストリの中には有効期限を公開していないところもあります）。

whois example.com | grep -iE "expir"

各権威ネームサーバーにSOAのシリアル番号を問い合わせます。シリアル番号が異なる場合、いずれかのネームサーバーが最新のゾーンをまだ取り込んでいないか、変更がまだコピー中です。

for ns in $(dig +short NS example.com); do echo "$ns $(dig +short SOA example.com @$ns | awk '{print $3}')"; done

パブリックリゾルバーと権威サーバーの回答を比較します。権威サーバーが正しくパブリックリゾルバーが正しくない場合、レコードが間違っているのではなく、キャッシュの期限切れを待っている状態です。

dig +noall +answer example.com @1.1.1.1
dig +noall +answer example.com @<one of the NS names above>

そのうえで、正しい場所で修正します。期限切れのドメインはレジストラで、誤ったネームサーバーはレジストラで、誤ったレコードはDNSプロバイダーで直します。

移行前にまずTTLを下げる

リゾルバーは、TTLが示す期間だけ回答を保持します。AレコードのTTLが86400秒（1日）なら、変更後も1日間は一部の訪問者が古いサーバーにアクセスし続ける可能性があります。

1. 権威サーバーで現在のTTLを確認します。dig +noall +answer example.com @<nameserver>の2列目です。
2. 変更の少なくとも旧TTL 1回分前に、TTLを300秒に下げます。TTLが1日なら、1日か2日前です。
3. 変更を行い、権威サーバーとパブリックリゾルバーの両方で反映を確認します。
4. 旧TTLの期間が過ぎるまで、古いサーバーを稼働させておきます。
5. すべてが新しい場所を指すようになったら、TTLを再び上げます。

監視すべきもの

• すべてのクライアントドメインの有効期限。リマインダーはクライアントだけでなく、あなたにも届くようにします。
• 重要なレコード。サイトのAレコード（またはAAAAレコード）と、クライアントのメールが依存している場合はMXレコードです。
• それらのレコードの存在だけでなく値。誤ったサーバーを指すレコードも検知できるようにします。
• ページそのもの。前述の更新案内ページの段階では、ページの内容を読むチェックだけが違いに気づけます。

BaromioのDNSモニターとドメインアラートでカバーできること

• DNSモニター：ホスト名に対して1種類のレコード（A、AAAA、MX、CNAME、TXTのいずれか）を、Baromioのサーバーにある通常のリゾルバー経由で、プランが許す頻度で照会します。Freeプランでは5分ごと、Proプランでは1分ごと、Businessプランでは30秒ごとです。レコードが1件も返らなければ失敗になります。期待値を設定すると、回答の最初のレコードにその文字列が含まれない場合も失敗になります（大文字と小文字は区別しません）。そのためgoogle.comはaspmx.l.google.comのようなMXレコードに一致します。複数のAレコードを持つ名前では最初のレコードが変わることがあるため、期待値は空にしておくか、すべてに共通する部分を使ってください。
• DNSモニターがしないこと：確認は1台のサーバーからのみで、ネームサーバーやSOAシリアル番号の比較、リゾルバー間の伝播テストは行いません。これらには前述の手順を使ってください。
• ドメイン有効期限：HTTPまたはキーワードモニターでドメイン有効期限を監視をオンにします（初期設定ではオフです）。Baromioは1日1回WHOISからドメインの有効期限を読み取り、残りが30日、14日、7日になった日に、メールと接続済みのSlack、Discord、Webhookチャネルで通知します。7日前のアラートの後に通知はないため、それを最後の通知と考えてください。モニターカードには残り日数を示すWHOISバッジが表示されます。レジストリが有効期限を公開していない場合、日付は表示されません。.co.ukのような2つの部分からなるサフィックスのドメインは、まだ照会できません。手動で確認してください。
• プラン：どちらもすべてのプランで利用できます。Freeは20モニター、Pro（月額9 EUR）は30モニター、Business（月額29 EUR）は100モニターまでです。

クライアントごとのチェックリスト

1. レジストラ、DNSプロバイダー、更新費用を誰が支払うかを書き留めます。
2. 更新のリマインダーがあなたに届くこと、自動更新に有効なカードが登録されていることを確認します。
3. サイトのメインレコードに期待値付きのDNSモニターを設定し、メールが重要ならMXにもう1つ設定します。
4. サイトのHTTPまたはキーワードモニターでドメイン有効期限アラートをオンにします。
5. DNSを変更する1日か2日前にTTLを下げ、旧TTLの期間が過ぎるまで古いサーバーを稼働させておきます。

出典

• ICANN、Expired Registration Recovery Policy：リマインダーのタイミング（2.1）、期限切れ後のDNS名前解決経路の遮断と更新案内のランディングページ（2.2）、削除後30日間のRedemption Grace PeriodとDNS名前解決の無効化（3.1、3.2）。