シームレスなDNS移行：ハウツーガイド

新しい家に引っ越したときに最初にやるべきことの1つは、新しい郵送先住所に郵便物が送られるよう手続きすることです。この手続きは必ずしも複雑ではありませんが、重要です。そうしないと、重要な郵便物が古い住所に送られ、あなたも送り主も、郵便物が送られていないことに気付かない可能性があります。

DNS移行も同様です。適切に行われないと、Webサイトにユーザーがアクセスできなくなったり、Eメールが送信できなくなって顧客とのコミュニケーションに問題が生じたり、連携が中断したりする可能性があります。基本的に、顧客は正しい住所で貴社に連絡できない可能性があり、れがさまざまな悪影響につながるおそれがあります。

ドメイン・ネーム・システム（DNS）は、インターネットの電話帳やディレクトリのような役割を果たします。ユーザーは、184.85.75.7のような数字列の代わりに、IBM.comのような覚えやすいドメイン名を使ってウェブサイトにアクセスできます。

しかし、DNSには単純な変換以上のものが伴い、マネージドDNSプロバイダーのサービス品質が、パフォーマンス、信頼性、レイテンシー、セキュリティー、プライバシーなどに影響する可能性があります。プロバイダーのDNSサービスが期待やニーズに応えていない場合、企業は新しいプロバイダーを探すかもしれません。その場合、DNS移行を計画する必要があります。

DNS移行は、組織がドメインのDNSレコードと設定をあるプロバイダーから別のプロバイダーに転送するもので、よく言われるほど大変な作業である必要はありません。ただし、それにはリスクがあり、適切に実行しないと問題が生じるおそれがあります。DNS移行でエラーが発生すると、ダウンタイムやネットワークの脆弱性などが生じかねません。こうした事態にならないようにするための方法をご紹介します。

DNSルックアップ・プロセスの詳細については、こちらをご覧ください。

簡単に答えると、すべてのDNSプロバイダーが同じサービスまたはサービス品質を提供しているわけではないということです。パフォーマンスは主要な機能ですが、問題はそれだけではありません。

例えば、DNSプロバイダーは、DNSスプーフィングを防止したり、既知または疑わしい悪意のあるドメインへのアクセスをブロックするセキュリティー機能を提供することがあります。また、監視やログ機能もプロバイダーによって異なります。一部のDNSプロバイダーは、複数の冗長なウェブ・サーバーがDNSクエリーを処理して特定のサーバーへの負荷を回避するためのフェイルオーバー向けロード・バランシングや、ユーザーに近い場所でコンテンツをキャッシュするためのグローバルコンテンツ・デリバリー・ネットワーク（CDN）を提供しています。もちろん、コストもDNSプロバイダーを変更する際の要因となることがあります。

ビジネス・リーダーは、ビジネス・ニーズに最適なサービスを選択する必要があります。こうしたニーズは進化することが多く、DNSの要件も同様に進化する可能性があります。現在のDNSプロバイダーのサービスが企業のニーズを満たさなくなった場合、ビジネス・リーダーはDNSの記録と管理を新しいプロバイダーに移行することを検討する場合があります。

一般に、多くの企業がこの移行を先延ばしにする大きな理由は、移行があまりにも困難で、変更がダウンタイムにつながると感じているからです。これは当然の懸念ですが、慎重な計画と実行によって軽減できます。

DNS移行の最初の手順は、移行の理由を決めることです。企業が現在得ていないメリットとは何でしょうか？企業が解決する必要がある問題は何ですか？たとえば、ある企業が小規模なインターネット・サービス・プロバイダー（ISP）のDNSを使用している場合、解決時間が3桁ミリ秒に達する場合があります。その場合、速度の向上が優先事項になるかもしれません。

移行する理由を特定したら、ITチームはさまざまなサービスを比較して、機能、サービス、コストの適切な組み合わせを見つけることができます。プロバイダーによって移行のオンボーディングの詳細は異なりますが、従うべき一般的なガイドラインがいくつかあります。

移行チームがプロバイダーを選定したら、前のDNSプロバイダーからすべてのレコードおよび関連情報を収集する必要があります。これらのレコードには以下が含まれることがあります。

これらのレコードは、ドメイン名からIPアドレスへの直接変換を行います。AレコードはIPv4アドレスにマッピングされ、AAAAレコードはIPv6アドレスにマッピングされます。IPv6 はより一般的になりつつあります。これは、はるかに多くの一意のIPアドレスを提供し、いくつかの基本的なセキュリティーと速度を向上させる機能を備えています。

正規名レコード（CNAMEレコード）は、エイリアスドメインを正規ドメインに誘導します。つまり、このタイプのレコードは、サブドメインをドメインAまたはAAAAレコードにリンクするために使用されます。

代行ネームレコード（DNAMEレコード）は、1つのレコードで複数のサブドメインをリダイレクトし、別のドメインに指定するために使用されます。

証明機関承認レコード（CAAレコード）を使用すると、ドメイン所有者は、自分のドメインの証明書を発行できる証明機関（CA）を指定できます。CAは、デジタル証明書を発行することでWebサイトのIDを検証し、Webサイトを暗号キーに接続する組織です。

テキスト（TXTレコード）には、ドメインとサブドメインに関連するテキスト情報が保存されます。テキスト・レコードにより、ストレージを利用して、フレームワーク（SPF）レコードとEメール検証レコードを保存できます。DKIMレコードとDMARCレコードはTXTレコードに保存され、メールサーバーが「メッセージが信頼できる送信元から送信されている」ことを確認するのに役立ちます。

開始権限（SOAレコード）には、ドメインに関する重要な管理情報が保存されます。この情報には、ドメイン管理者の電子メールアドレス、ドメインの更新に関する情報、サーバーが情報を更新すべき時期などを含めることができます。

ネームサーバー（NSレコード）は、どのDNSサーバーがドメインの権威DNSサーバーとして機能しているかを示します。権威DNSサーバーには、特定のドメインとそれに対応するIPアドレスに関する最終情報が含まれています。NSレコードは、ドメインが保持するさまざまなレコードすべてを指します。NSレコードがなければ、ユーザーはWebサイトにアクセスできません。

DNSゾーンはDNS名前空間内の区分です。たとえば、IBM.comにはresearch.ibm.comという別のDNSゾーンがあります。これらのサブドメインは十分に大きいため、個別の管理と監視によってメリットが得られます。DNSゾーン・ファイルには、前述のファイル・タイプ（SOAレコード、AおよびAAAAレコードなど）のほとんどが含まれます。

他にもDNSレコードの種類はあります。詳細については、このガイドをご覧ください。

一部のプロバイダーは、DNSレコードを収集、エクスポート、インポートする自動化機能を提供していますが、レコードが欠落していると重大な問題が発生する可能性があるため、手動バックアップを実行することも賢明です。また、これらのファイルのコピーを安全な場所に保管する必要があります。

このプロセスで起こり得る問題の一つは、DNSSEC（Domain Name System Security Extensions）である可能性があります。DNSSECは、署名を検証することで正確性を確保し、DNSスプーフィングやその他の攻撃を防ぐことで、価値ある一連のセキュリティー保護機能を提供します。

しかし、DNSの移行プロセスでは異なる署名アルゴリズムが導入され、チェーンが壊れたり、機能停止が発生したりすることがあります。この問題にはさまざまな解決策があり、一部のプロバイダーは、そのセキュリティーを維持するDNSSEC固有の移行ツールを提供しています。他の企業にとっては、移行前にDNSSECを無効化し、移行が完了したら再度有効にすることが必要な場合があります。

もう一つの推奨される方法は、存続時間（TTL）の値を下げることです。これは、再帰リゾルバ（またはDNSクエリーの最初の停止点である再帰サーバー）が最近アクセスしたWebサイトのIPアドレスをキャッシュに保存する時間の長さです。キャッシュを使用すると IPアドレスを再度検索する必要がなくなり、接続の高速化が可能になります。

TTLが24時間に設定されている場合、ユーザーがその期間内にDNSサーバーを移行したサイトにアクセスしようとすると、ブラウザは古いアドレスに移動しようとするため、エラーが発生する可能性があります。TTLを非常に低い値（おそらく数分）に設定すると、この問題を回避できます。

移行は一度に行うのではなく、段階的に実行することをお勧めします。ステージングにより、移行チームは運用全体を通じて何が問題だったのかを慌てて調べるのではなく、各機能のエラーを個別にチェックできます。

チームが既存のDNSドキュメントをエクスポートし、新しいDNSプロバイダーのサービスでインポートしたら、途中で失われたものがないことを確認するためにドキュメントをチェックして検証する必要があります。[dig]のようなツールは検証に役立ちます。[Dig]（ドメイン情報グロッパー）は、基本的なIPアドレスからTXT、SOAなどのDNSドキュメントをチェックできるコマンドライン・ツールです。nslookupもコマンドライン・ツールで、[dig]よりもシンプルですが、返される結果の詳細度は低くなります。

その後、チームは、Webホスティング、Eメール・サービス、API、その他のサードパーティー・サービスなど、段階ごとに移行を開始できます。移行の進行に合わせて、チームの誰かがそれぞれをチェックしてトラブルシューティングすることをお勧めします。DNSSECの有効化など、詳細設定を構成します。これらがすべてテスト・サーバーでテストされると、チームはレジストラで情報の更新に進むことができます。

もし企業が利用しているDNSプロバイダーとドメイン登録業者が別の場合（例えば、DNSにIBM NS1 Connectを、ドメイン登録にGoDaddyを使用している場合）、チームはドメイン登録サービスにログインしてネーム・サーバー・レコードを更新する必要があります。DNSとドメイン登録を同じプロバイダーで行っている場合、多くの場合この作業は自動で行えます。ホスティング・プロバイダーを変更しない限り、ウェブ・ホスト側で何かを変更する必要はありません。

古いDNSはまだ削除しないことが重要です。これはDNS伝播によるものです。DNSレコードはインターネット全体で即座に変更されません。分散したドメインサーバーがレコードを検索して更新するのに時間がかかります。チームは、WhatsMyDNS.netなどのオンライン・ツールを使用して、レコードのステータスを定期的に確認できます。通常、ほとんど1～2日かかりますが、その間は、古いDNSサービスと新しいDNSサービスを実行し、それらのドメインサーバーがレコードを更新するようにする必要があります。これにより、ユーザーはシステム停止を経験せずに済みます。

伝播が完了すれば、移行作業は基本的に完了です。わずかな仕上げ作業だけが残ります。これには以下が含まれます。

TTLを元に戻す：ユーザー向けのキャッシュを有効にするため、TTLを元の24時間または以前の値に戻します。

内部ドキュメントの更新：混乱を避けるために、DNS情報（アカウント番号、請求サイクルなど）が組織の記録内で更新されていることを確認します。

監視：移行後のパフォーマンスやその他のメトリクスを確認します。ITチームは、DNSログにエラーやタイムアウトがないか確認し、新しい応答時間を追跡し、ダウンタイムについてアラートを設定し、伝播を定期的にレビューできます。多くのDNSプロバイダーには、内部監視ツールがあります。サードパーティ製ツールも利用できます。

マネージドDNSサービスの詳細については、こちらをご覧ください。