Vanity NS の変更は、「新しいネームサーバー名にIPアドレスを割り当てる（ホストの登録＝グルーレコード）」「新しいサーバーで全ゾーンが応答することを確かめる」「各ドメインのNSを切り替える」「古いサーバーを猶予期間のあいだ残す」の順に進めれば、名前解決を止めずに移行できます。この記事では、Vanity NS の仕組みを確認したうえで、変更の種類ごとの作業、確認のコマンド、DNSSEC を使っている場合の注意を説明します。
Vanity NSとは
Vanity NS は、DNS 事業者の実際のネームサーバーに、自社のブランドの名前（例: ns1.example-brand.com）を付けて使う方法です。ホスティング事業者や制作会社が、顧客のドメインの NS に自社名を表示したいときによく使います。中身のサーバーは DNS 事業者のもので、名前だけを自社のものにしている点が、自前で DNS サーバーを運用する場合との違いです。
ns1.example-brand.com は example-brand.com の配下の名前なので、その IP アドレスを .com のレジストリに「ホスト（ネームサーバー）」として登録します。登録は、example-brand.com を管理しているレジストラの管理画面から行います。これがグルーレコードの元になります。レジストラによって「ネームサーバーのホスト名登録」「Personal DNS Server」「子ネームサーバー」など呼び方が違います。
あわせて、example-brand.com のゾーン（DNS 事業者側）にも、ns1.example-brand.com の A（と AAAA）レコードを同じ IP アドレスで登録しておきます。レジストリに登録したグルーと、ゾーンの中のレコードが食い違うと、確認ツールで警告が出たり、リゾルバーによって違う IP アドレスに問い合わせたりします。
DNS 事業者側の機能として提供されている場合もあります。たとえば Cloudflare のカスタムネームサーバーは上位のプランの機能で、使える範囲や手順はプランと時期で変わります（2026年10月時点）。事業者の機能を使う場合は、その事業者の手順書を優先してください。
変更の種類を先に決める
「Vanity NS を変える」と言っても、作業は次の3つに分かれます。どれに当たるかで手順が変わります。
- 名前はそのまま、裏の DNS 事業者（IP アドレス）を変える: 顧客ドメインの NS 設定は変えずに済みます。登録済みホストの IP アドレスの変更が中心です
- 名前を変える（ブランド名や使うドメインの変更）: 新しい名前のホストを登録し、すべての顧客ドメインの NS を新しい名前に切り替えます
- Vanity NS をやめ、事業者の標準の NS に戻す: 各ドメインの NS を標準の名前に変え、最後に Vanity NS のホスト登録を削除します
以下は、影響が大きい2を中心に、1と3で異なる点を添えて説明します。例では、旧名を ns1.example-brand.com、新名を ns1.new-brand.com とします。
手順
1. 現状を記録する
最初に、今の状態を記録します。後で戻すときの手がかりになります。
# Vanity NS の IP アドレス（DNS で引いた値）
dig +short ns1.example-brand.com A
dig +short ns1.example-brand.com AAAA
# レジストリに登録されているホストの IP アドレス（.com の場合、RDAP で確認）
curl -s https://rdap.verisign.com/com/v1/nameserver/ns1.example-brand.com
# 顧客ドメインごとの NS
dig +short customer-a.com NSRDAP の応答（JSON）の ipAddresses に、レジストリに登録されている IP アドレスが入っています。.com 以外の TLD では、そのレジストリの RDAP サーバーに問い合わせます（RDAP サーバーの一覧は IANA が https://data.iana.org/rdap/dns.json で公開しています）。
あわせて、その Vanity NS を使っているドメインの一覧を作ります。管理画面の一覧と、実際に dig で引いた結果を突き合わせると、記録漏れのドメインが見つかります。
2. 新しいサーバーで全ゾーンが応答するようにする
新しい DNS 事業者（またはサーバー）に、すべてのゾーンを用意します。切り替える前に、新しいサーバーへ直接問い合わせて、主要なレコードが現在と同じ値を返すことを確かめます。
dig @203.0.113.10 customer-a.com SOA
dig @203.0.113.10 customer-a.com A
dig @203.0.113.10 customer-a.com MXゾーンの中の NS レコードと、SOA レコードの主ネームサーバー名も、新しい Vanity NS の名前にしておきます。親ゾーンの NS とゾーン内の NS が食い違うと、確認ツールで警告が出たり、一部のリゾルバーで挙動が不安定になったりします。
3. TTLを下げておく
切り替えの数日前に、ゾーン内の NS レコードや主要なレコードの TTL を短くしておくと、切り替え後に古い情報が残る時間を減らせます。ただし、親ゾーン（.com など）に登録される NS とグルーの TTL はレジストリが決めていて、.com では 172800 秒（2日）です。こちらは自分では短くできないため、切り替え後も最低その期間は古いサーバーが問い合わせを受けると考えておきます。
4. 新しい名前のホストを登録する
ns1.new-brand.com のホスト登録は、new-brand.com を管理しているレジストラで行います。.com を含む多くのレジストリでは、ホストの登録はその名前の親ドメイン（ここでは new-brand.com）を管理するレジストラからしかできないためです。旧名の親ドメイン example-brand.com のレジストラで登録するのではない点に注意してください（同じレジストラで両方を管理している場合は、同じ管理画面で済みます）。
new-brand.comのレジストラの管理画面で、ホスト名ns1.new-brand.comと IP アドレスを登録する。IPv6 で応答させるなら IPv6 アドレスも登録するnew-brand.comのゾーンに、ns1.new-brand.comの A（と AAAA）レコードを同じ IP アドレスで登録する- ネームサーバーは障害に備えて最低2台（
ns1・ns2など）用意し、できれば別のネットワークに置く
登録がレジストリに反映されたかは、RDAP で確かめます。
curl -s https://rdap.verisign.com/com/v1/nameserver/ns1.new-brand.com登録した IP アドレスが ipAddresses に出れば反映されています。dig @a.gtld-servers.net で確かめる方法もありますが、そのホストを NS に使うドメインがまだ無い段階では、グルーが応答に出ないことがあります。
種類1（名前はそのまま、IP アドレスを変える）の場合は、この手順で旧名のホストの IP アドレスを新しいものに更新し（example-brand.com のレジストラで行います）、ゾーン内の A・AAAA レコードも同じ値に変えます。手順5は不要です。
5. 顧客ドメインのNSを切り替える
各ドメインのレジストラで、NS を新しい Vanity NS の名前に変更します。ドメイン数が多い場合は、重要度の低いドメインで先に1件試し、名前解決とメールの送受信に問題がないことを確かめてから残りに進みます。
顧客がドメインを自分のレジストラで管理している場合は、変更をお願いする連絡が要ります。変更する値、期限、変更しなかった場合に何が起きるかを、短く具体的に伝えます。
6. 切り替えを確認する
# ルートから順にたどって、新しい NS に到達しているか
dig +trace customer-a.com
# 親ゾーンに登録された NS とグルー（ADDITIONAL に新しいホストの IP アドレスが出る）
dig @a.gtld-servers.net customer-a.com NS +norec顧客ドメインと NS の名前がどちらも .com の場合、切り替えたドメインの NS を .com のサーバーに問い合わせると、応答の ADDITIONAL に、新しいホストの IP アドレス（グルー）が表示されます。手順4で登録した値と一致しているかを確かめます。
複数の地域から確かめたいときは、DNS の伝播確認ツールも使えます。表示される結果は各地のリゾルバーのキャッシュに左右されるため、TTL が切れるまでは新旧が混ざって見えるのが普通です。
7. 古い設定を片付ける
古いサーバーは、すべてのドメインの切り替えが済み、親ゾーンの TTL が過ぎるまで動かしたままにします。数日の余裕を見ておくと安心です。その後、example-brand.com のレジストラで古いホスト名の登録を削除します。
まだそのホスト名を NS に使っているドメインがあると、ホストの削除は多くのレジストリで拒否されます（レジストリとレジストラの間の仕様 EPP の RFC 5732 でも、他のドメインから参照されているホストは削除しないよう定めています）。削除できないときは、まだ切り替えていないドメインが残っていないかを確かめてください。
DNSSECを使っている場合
DNSSEC を有効にしているドメインで、DNS 事業者ごと変える場合は特に注意が要ります。親ゾーンに登録した DS レコードと、新しいサーバーが署名に使う鍵が一致しないと、DNSSEC を検証するリゾルバーでは名前解決に失敗します。
- 新旧の事業者が鍵の受け渡し（相手の鍵をゾーンに加える方式）に対応していれば、それに従って移行する
- 対応していなければ、DS レコードを先に削除し、親ゾーンの TTL が過ぎてから NS を切り替え、新しい事業者で署名を有効にしてから新しい DS を登録する
DS を外している間は署名の保護がない状態になるため、作業の期間はできるだけ短くします。種類1（名前はそのまま、事業者を変える）の場合も同じ注意が必要です。
まとめ
- Vanity NS は、DNS 事業者のサーバーに自社の名前を付ける仕組み。名前の IP アドレスは、その名前の親ドメインのレジストラでホストとして登録し、ゾーンにも同じ A・AAAA レコードを置く
- 作業は「IP アドレスだけ変える」「名前を変える」「やめる」の3種類に分かれる。どれに当たるかを先に決める
- 新しいサーバーで全ゾーンが応答することを確かめてから、ホストの登録、NS の切り替えへ進む
- 登録の反映は RDAP で、切り替え後のグルーは
dig @a.gtld-servers.netで確かめる - 親ゾーンの TTL（
.comは2日）は自分で短くできないため、古いサーバーは切り替え後も数日残す - DNSSEC を使っている場合は、DS レコードの扱いを切り替えの前に決めておく
関連記事：