3つの役割。担当企業が別々なことも多い
DNS委任の仕組み:レジストラとプロバイダー
DNS委任とは、DNSの名前階層の一部について、その権限を別のネームサーバー群に割り当てる仕組みです。ドメインレジストラは通常、レジストリに届け出るネームサーバーの委任を管理し、DNSホスティングプロバイダーは、その委任で指定されたゾーンのレコードを提供します。両者は関連していますが、別々の責任です。レジストラがA、MX、TXTレコードをホストしているとは限りません。また、DNSプロバイダーは、レジストラ側の設定も管理していない限り、親の委任を変更できません。ダッシュボードで変更したレコードが公開側に表示されないとき、まず確認すべきことの1つが、委任が誤っていないか、想定外になっていないかです。
親から子へ、権限をたどる
再帰リゾルバーは、信頼できるルート情報から始めて、DNS階層をたどりながらリファーラルを追っていきます。ルートは .com のようなトップレベルドメインを指し、TLDはそのドメインの権威ネームサーバーを指し、それらのネームサーバーがドメインのレコード、またはさらなる委任を提供します。各リファーラルは、次の部分を担当するのは誰かを示します。委任があるおかげで、すべてのレコードを1つのグローバルなサーバーが保持しなくても、個別に管理される数百万のゾーンが共存できます。同時に、ある引き継ぎでミスが起きると、本来は正しいゾーンに到達できなくなることもあります。
- 移行先のDNSプロバイダーで、対象のゾーンを作成し、レコードを登録する。
- プロバイダーが割り当てた権威ネームサーバーのホスト名を確認する。
- レジストラまたは親側のコントロールプレーンで、ドメインの委任を設定する。
- 公開されているNSの応答を確認し、権威サーバーに直接問い合わせる。
- 切り替え後、ウェブサイト、メール、所有確認の主要なレコードを確認する。
委任されたネームサーバーが、自身が担当するドメインの内部にある場合、リゾルバーがそのサーバーに尋ねることなくIPを見つけられるよう、親側にグルーレコードが必要になることがあります。プロバイダーやレジストラは、通常この設定を案内してくれますが、独自のネームサーバーを運用する場合は、この依存関係を理解しておく必要があります。入力ミス、グルーの欠落、委任の不整合があると、DNSサーバーが動いていても、タイムアウトや障害につながることがあります。マネージドプロバイダーが提供する標準のネームサーバーのホスト名を使えば、こうした低レベルの詳細を自分で管理せずに済むことが多くなります。
誤ったプロバイダーでも正しく見える理由
DNSのダッシュボードにゾーンが完全に表示されていても、そのプロバイダーが公開ドメインの権威ではないことがあります。ドメインがまだ以前のホストに委任されたままだったり、レジストラの更新が完了していなかったり、サブドメインが別に委任されていたりするケースです。そのような場合、有効になっていないゾーンを編集しても、一般の公開リゾルバーから見える内容は何も変わりません。プロバイダーのダッシュボードの外からNSレコードを確認し、そのゾーンに割り当てられたネームサーバーと比較してください。サブドメインに独自のNS委任がある場合、その枝のレコードは親とは独立して管理されていることがあります。
| コントロールプレーン | 通常管理するもの |
|---|---|
| レジストラ / レジストリ | ドメインの登録と、親レベルのネームサーバー委任 |
| 権威DNSホスト | 委任されたゾーン内のレコード |
| 再帰リゾルバー | クライアントに代わる検索と、キャッシュされた応答 |
| アプリケーションホスト | DNSの名前解決後に到達するウェブサイトやサービス |
プロバイダーを移行する間は、委任とキャッシュが切り替わるまで、古いゾーンを利用可能にしておきます。事前にレコードのTTLを下げておくことが役立つのは、古いTTLが切れるのに十分な時間が経ったあとだけです。ウェブサイトのアドレスだけでなく、メール、所有確認、サブドメインのレコードもコピーしてください。委任を変更したら、新しい権威サーバーに問い合わせて、準備したゾーンと応答を比較します。移行が完了したと言えるのは、想定した名前が意図した権威から正しく解決され、依存するサービスのテストも済んだときです。レジストラのフォームが成功を報告しただけでは完了ではありません。
さらに詳しくは、NSレコードとは、ネームサーバーとドメインの委任、DNS移行の確認方法 をご覧ください。公開の DNS検索 では、リゾルバーから見える答えを確認でき、権威への問い合わせはゾーンそのものの検証に役立ちます。レジストラの委任とレコードのホスティングを切り分けることが、DNSの変更を実際にどこで行う必要があるのかを診断する鍵です。
委任の引き継ぎを明確にする
委任の引き継ぎを確実に行うには、レジストラの変更を申請する正確な日時、それを元に戻せる担当者、完了を確認するリゾルバーのチェック内容を明確にしておきます。移行期間中は、旧DNSプロバイダーと新DNSプロバイダーの両方に、権限のある連絡先を確保しておいてください。ドメインがカスタムネームサーバーや委任された子ゾーンを使っている場合は、それらの依存関係も運用手順書に含めます。レジストラの更新に成功しても、各ネームサーバーのホスト名が名前解決できること、すべてのサービスレコードがコピーされたことは証明されません。アカウントの外から、NSデータ、代表的なAとAAAAの応答、MXの宛先、重要なTXTポリシーを確認します。こうすれば、権限と、委任されたゾーンに依存するサービスの両方を網羅したチェックリストが手に入ります。移行後は、新しい権威がすべての想定レコードを提供していることをチームが確認し、ロールバックの期間が終わってから、旧プロバイダーを廃止します。日付、委任の値、確認結果は変更チケットに残しておくと、将来の管理者がどのDNSサービスがそのドメインを管轄しているかを把握できます。
ドメインの公開DNSアドレスを調べたい場合は、Domain IP Lookupツールをお試しください。
このテーマの無料ツール
関連記事
並行して使われる2つのアドレス体系
IPv4
192.0.2.10
32ビット、約43億のアドレス、枯渇
IPv6
2606:4700::6810:84e5
128ビット、340澗のアドレス
IPv4アドレスの枯渇と、IPv6へのゆっくりとした移行
新規のIPv4アドレスは、何年も前に世界から尽きました。それ以来、何が運用を支えてきたのか、そして移行がまだ終わっていない理由を解説します。
アラート対象にすべきシグナル
ドメインポートフォリオ全体のDNS変更を監視する
1つのドメインのDNSを手作業で見張る方法は、数十、数千のドメインには通用しません。変更を早期に捉えるための実践的な方法を紹介します。
段階的な切り替えは一括切り替えに勝る
Blue
トラフィック100%
加重分割
95/5、次に50/50
Green
トラフィック100%
ブルーグリーンデプロイメントとDNS切り替え
DNSの変更で2つの環境間のトラフィックを切り替える方法は、理屈の上では簡単です。しかし実際には、TTLとキャッシュが話を複雑にします。