Vanity NS（独自ドメイン名のネームサーバー）は、DNSサービスのネームサーバーに ns1.example.com のような自社の名前を付けて公開する仕組みです。プライマリNS（ゾーンの原本を持つサーバー）と組み合わせるときは、「レジストラのグルーレコード」「ゾーン内のNSレコードとA/AAAAレコード」「SOAのプライマリ名」の3つを同じ内容にそろえることが要点です。この記事では、構成の考え方、設定の順番、切り替え後の確認方法までを説明します。
Vanity NS とプライマリNSの関係を整理する
最初に用語を整理しておきます。混乱の多くは、「プライマリ」という言葉が2つの意味で使われることから生まれます。
- ゾーンの原本を持つサーバー（プライマリ／マスター）: レコードを編集する場所です。セカンダリはここからゾーン転送で内容を受け取ります。
- NSレコードの先頭に書かれたサーバー:
ns1と名付けられたサーバーを「プライマリ」と呼ぶ習慣がありますが、リゾルバーはNSレコードの順番を優先度として扱いません。応答の速さなどを基準に問い合わせ先を選ぶため、ns1に特別な役割はありません。
Vanity NS は「公開する名前」の話で、プライマリは「どこでゾーンを管理するか」の話です。この2つを分けて考えると、組み合わせ方は次の2通りに整理できます。
- DNSサービス1社に Vanity NS を付ける構成: ゾーンの原本もDNSサービス上にあり、公開名だけを自社ドメインにします。運用は最も単純です。
- 非公開のプライマリ（ヒドゥンプライマリ）と Vanity NS の構成: 自社のサーバーでゾーンを編集し、公開用のセカンダリ（外部のDNSサービスなど）へ転送します。外から見えるNSは Vanity NS の名前だけにします。
設定前に確認すること
DNSサービスが Vanity NS を公式にサポートしているか
Vanity NS は、自社の名前をDNSサービスのネームサーバーのIPアドレスに向けるだけなので、仕組みとしてはどのサービスでも作れます。ただし、サービス側がIPアドレスを変更すると、自分で登録したグルーレコードが古いまま残り、名前解決が止まります。サービスが Vanity NS（ホワイトラベルNS、カスタムネームサーバーなど名称はさまざま）を公式機能として提供しているか、IPアドレスが固定される条件は何かを事前に確認してください。対応状況やプランの条件はサービスごとに変わります（2026年10月現在）。
AWS の Route 53 では、再利用可能な委任セット（reusable delegation set）を作り、そのセットでホストゾーンを作成するとネームサーバーの組み合わせが固定されます。
# 再利用可能な委任セットを作る（caller-reference は一意な任意の文字列）
aws route53 create-reusable-delegation-set --caller-reference vanity-2026-10
# 返ってきた Id を指定してホストゾーンを作る
aws route53 create-hosted-zone --name example.com \
--caller-reference zone-2026-10 --delegation-set-id （委任セットのId）割り当てられたネームサーバーのIPアドレスを控える
Vanity NS の名前に設定するIPアドレスは、DNSサービスのネームサーバー名を引いて調べます。IPv6 にも対応させるなら AAAA も控えます。
dig +short A ns-123.awsdns-45.com
dig +short AAAA ns-123.awsdns-45.com設定の手順
手順1：ゾーンに Vanity NS の名前とアドレスを登録する
ゾーンの中に、Vanity NS の名前（A/AAAAレコード）と、ドメイン自身のNSレコードを登録します。SOAの1つ目の値（MNAME）には、ゾーンのプライマリとして扱う名前を書きます。ヒドゥンプライマリ構成でプライマリを外に見せたくない場合は、Vanity NS のいずれかを書く運用が一般的です。ただし、セカンダリのサービスによってはSOAの書き換えを独自に行うものもあるため、仕様を確認してください。
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2026102201 ; serial（変更のたびに増やす）
3600 ; refresh
900 ; retry
1209600 ; expire
3600 ) ; negative cache TTL
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
ns1 IN A 192.0.2.10
ns2 IN A 198.51.100.10ここで、Vanity NS の名前とDNSサービスの本来の名前を混ぜてNSレコードに並べることもできます。動作上の問題はありませんが、同じIPアドレスを別名で並べても冗長性は増えません。別々のサービスを並べる場合は、どちらにも同じゾーン内容が配られていることが前提です。
手順2：レジストラにグルーレコードを登録する
ns1.example.com のように、委任するドメイン自身の配下にあるネームサーバー名を使う場合、親ゾーン（.com など）に名前とIPアドレスの組（グルーレコード）を登録しないと、リゾルバーはネームサーバーの場所にたどり着けません。レジストラの管理画面では「ホスト名の登録」「ネームサーバーホストの作成」などの名前で用意されていることが多く、表記はレジストラによって異なります。
登録するIPアドレスは、手順1でゾーンに書いたものと同じにします。親ゾーンのグルーと子ゾーンのA/AAAAレコードが食い違うと、どちらを見たリゾルバーかによって結果が変わり、原因の特定が難しくなります。
手順3：ネームサーバーを Vanity NS に切り替える
グルーの登録が反映されたことを確認してから、レジストラでドメインのネームサーバーを Vanity NS の名前に変更します。切り替え前には、ゾーンの中身（WordPress サイトの A レコード、メールの MX・SPF・DKIM、証明書のための CAA など）が新しいネームサーバーで同じように返ることを確かめておきます。サイトだけでなくメールやSSL証明書の更新も DNS に依存しているため、ここを確認せずに切り替えると、Webは見えるのにメールが届かないといった症状が後から出ます。
親ゾーン側のNSレコードのTTLは自分では変更できず、TLDによっては1〜2日ほどの長さがあります。古いネームサーバーはこの期間が過ぎるまで同じ内容で動かしておきます。
ヒドゥンプライマリと組み合わせる場合
自社サーバーをプライマリにする場合は、公開用のセカンダリだけにゾーン転送を許可し、変更を通知します。BIND（9.16 以降の表記）の例です。TSIG鍵の名前やIPアドレスは環境に合わせて置き換えてください。
zone "example.com" {
type primary;
file "/etc/bind/zones/example.com.zone";
allow-transfer { key "xfr-key"; };
also-notify { 192.0.2.53; 198.51.100.53; };
notify explicit;
};notify explicit; は、NSレコードに載っているサーバーではなく also-notify に書いた宛先だけに変更通知を送る設定です。ヒドゥンプライマリ自身はNSレコードに載せないため、この設定が合います。ゾーン転送はTSIGで認証し、プライマリのポート53はセカンダリからの接続だけを許可しておきます。
DNSSEC で署名する場合は、どこで署名するか（プライマリで署名して転送するか、セカンダリのサービスが署名するか）を先に決めます。署名の場所が二重になったり、DSレコードの登録と食い違ったりすると、検証するリゾルバーから名前解決できなくなります。
設定後の確認方法
親ゾーン（委任元）と子ゾーン（自分のネームサーバー）の両方に問い合わせ、内容が一致しているかを確認します。
# 親ゾーンに登録されたNSとグルー（.com の場合）
dig NS example.com @a.gtld-servers.net +norec
# 自分のネームサーバーが返すNS
dig NS example.com @ns1.example.com +short
dig NS example.com @ns2.example.com +short
# 各ネームサーバーのシリアルがそろっているか
dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short
# ルートからたどった委任の流れ
dig +trace example.com1つ目の結果の追加セクション（ADDITIONAL）に、グルーとして登録したIPアドレスが出ていれば親ゾーン側の設定は反映されています。.jp の場合は @a.dns.jp のように、そのTLDのネームサーバーに問い合わせます。SOAのシリアルがネームサーバーごとに違う場合は、ゾーン転送が止まっている可能性があります。
まとめ
- Vanity NS は公開名の話、プライマリはゾーンを管理する場所の話です。NSレコードの順番はプライマリを意味しません。
- DNSサービスが Vanity NS を公式に扱い、IPアドレスが固定される条件を満たしているかを最初に確認します。
- グルーレコード、ゾーン内のNS・A/AAAAレコード、SOAのMNAMEを同じ内容にそろえてから、ネームサーバーを切り替えます。
- ヒドゥンプライマリ構成では、ゾーン転送をTSIGで認証し、変更通知の宛先を明示します。DNSSECの署名場所も先に決めます。
- 切り替え後は親ゾーンと子ゾーンの両方に
digで問い合わせ、NSとシリアルの一致を確認します。