Azure App Service ドメインで取得したドメインを Azure DNS へ委任したいのに、ネームサーバーがいつまで経っても GoDaddy のまま変わらない…。本記事では症状の整理から、確認ポイント、最短で解決する「他レジストラへ移管して Azure DNS に切り替える」具体手順までをまとめます。
今回のトラブルの全体像（結論から）
結論から言うと、Azure の App Service ドメイン（裏側のレジストラが WildWestDomains / GoDaddy）で取得したドメインは、通常のレジストラと同じ感覚で「ネームサーバーを自分で変更する」ことができない場面があります。特に Azure ポータルの 「Delegate to Azure DNS zone（Azure DNS ゾーンへ委任）」 が失敗すると、ユーザー側で打てる手が一気に減り、48 時間以上待っても NS が切り替わらないという状態に陥りがちです。
この状況で「レジストラ側の NS を Azure DNS の NS に手動で変えてほしい」と思っても、App Service ドメインの仕組み上、レジストラ管理画面（GoDaddy/WildWestDomains 相当）へ入れない／入れても操作できないことがあり、自力での手動変更が不可能なケースが現実にあります。
そのため、根本的に解決して今後も安定して運用するなら、ドメインを他レジストラへ移管（transfer out）し、移管先の管理画面から Azure DNS の NS を設定するのが最短で確実です。移管してしまえば、以後は一般的なドメイン運用と同じ手順で Azure DNS を使えます。
症状を整理：Azure DNS に委任したいのに NS が変わらない
今回のケースは、次のような条件が重なっています。
| 項目 | 内容 | ポイント |
|---|---|---|
| 対象ドメイン | zoleaf.nl | ドメイン自体は Azure の App Service ドメイン機能で取得 |
| 裏側レジストラ | WildWestDomains / GoDaddy | Azure ポータルの操作が「レジストラ操作の代行」になっている |
| やりたいこと | Azure DNS ゾーンを作成し、NS を Azure DNS に変更してレコードを Azure 管理に統一 | 委任が完了すると Azure DNS の NS が権威になる |
| 押した操作 | 「Delegate to Azure DNS zone」 | 本来はレジストラ側の NS を自動更新する |
| 現象 | 48 時間以上経っても NS が ns09.domaincontrol.com / ns10.domaincontrol.com のまま | GoDaddy 側 NS のまま＝Azure DNS の設定が外部に反映されない |
| 追加の困りごと | 「Advanced Management（詳細管理）」が開けない | レジストラ相当の画面に入れず、手動変更もできない |
ポイントは「Azure DNS 側のゾーンを正しく作れていても、レジストラ側（親側）の NS が変わらない限り、インターネットからは Azure DNS のレコードが見えない」という点です。DNS は階層構造なので、最上流の委任が止まると、下流（Azure DNS）の努力が反映されません。
なぜ起きる？App Service ドメインで詰まりやすい理由
App Service ドメインは「Azure の中でドメイン購入も更新もできて便利」な一方で、実体としては GoDaddy 系の仕組みの上に載っています。通常のレジストラで当たり前にできる操作が、Azure ポータル経由だと制限されたり、障害時に詰まりやすいのが弱点です。
| 運用で触りたい操作 | 一般的なレジストラ | App Service ドメインで起きがちなこと |
|---|---|---|
| ネームサーバー（NS）の変更 | 管理画面で即変更できる | Azure の自動操作に依存し、失敗するとユーザーが触れない |
| ドメインロック（レジストラロック） | ON/OFF を自分で切り替えられる | ロック解除の UI が無い／効かないことがある |
| DNSSEC（DS レコード） | DS 登録や削除を行える | 設定できない、またはトラブル時に解除できないことがある |
| 緊急時の代替運用 | 別の NS に逃がす、レコードを即修正など自由度が高い | 「詳細管理」が開けないと打ち手がほぼ無くなる |
| サポートの窓口 | レジストラに直接問い合わせ | Azure サポート経由になり、切り分けが複雑になりやすい |
今回のように「委任ボタンを押したのに NS が変わらない」「詳細管理に入れない」となると、レジストラ側をユーザーが直接触る手段が無いため、詰みやすいわけです。
移管の前に：まず確認しておきたいチェックポイント
「移管が最短」とはいえ、状況によっては確認や準備で事故を減らせます。次の項目を押さえてから動くと、切り替え時の混乱が減ります。
| チェック項目 | 確認方法 | 目的 |
|---|---|---|
| 現在の NS が何を指しているか | dig NS zoleaf.nl / nslookup -type=ns zoleaf.nl | 本当に GoDaddy 側 NS のままかを確定する |
| Azure DNS ゾーンの NS 値 | Azure DNS ゾーンの「概要」 | 移管後に設定する NS を正確に控える |
| Azure DNS ゾーンにレコードが揃っているか | A/CNAME/TXT/MX などを棚卸し | NS を切り替えた瞬間に名前解決できなくなる事故を防ぐ |
| DNS の TTL（キャッシュ時間） | 現行ゾーンの TTL を確認（可能なら事前に短くする） | 切り替え後の反映を早め、影響時間を短くする |
| 登録者メールが受信できるか | WHOIS 情報や管理情報を確認 | 移管承認メール等が届かない事故を防ぐ |
特に重要なのは「NS 切り替え前に Azure DNS 側へ必要レコードをすべて入れておく」ことです。NS を切り替える行為は、DNS の“参照先”をまるごと差し替える操作なので、空のゾーンへ切り替えると即座に解決不能になります。
確認コマンド例（そのままコピペでOK）
Windows の場合：
nslookup -type=ns zoleaf.nl
nslookup -type=soa zoleaf.nlmacOS / Linux の場合：
dig NS zoleaf.nl
dig SOA zoleaf.nl
dig +trace zoleaf.nl NS「+trace」は上流から辿るため、どこで委任が止まっているかの判断に役立ちます。
根本解決：App Service ドメインから他レジストラへ移管する
ここからが本題です。App Service ドメインのまま粘るより、ドメインを通常のレジストラへ移してしまうのが確実です。移管後は、レジストラの管理画面で NS を Azure DNS に変えるだけで、目的が達成できます。
移管のメリット（今回のようなトラブルに強くなる）
- ネームサーバー変更を自分で行える（自動処理の失敗に依存しない）
- ドメインロックや DNSSEC など、セキュリティ系の設定も自分で制御しやすい
- 更新年数の管理、連絡先情報、移管履歴などを一元管理できる
- 障害時に「自分で直せる範囲」が増え、復旧が早い
移管のデメリット（理解しておくと安心）
- 移管手数料が発生する場合がある（多くは更新1年延長込みの料金体系）
- 移管中は各種手続きメールの確認が必要
- ドメインの種類（TLD）によって移管ルールが異なることがある
とはいえ、今回のように「レジストラ画面に入れない」「NS を変えられない」状態は、運用上かなり致命的です。長期運用を考えるなら、自由度の高いレジストラへ移す判断は合理的です。
移管の手順：transfer out API → authCode（EPPコード）取得 → 移管申請
App Service ドメインからの移管で重要なのは、authCode（オースコード／EPPコード）の取得です。これが無いと、移管先レジストラで手続きを進められません。
移管できるかの前提：いわゆる「60日ルール」
一般に、ドメインを取得した直後や、移管直後は一定期間移管できないことがあります（いわゆる 60 日制限）。質問のケースでも、購入から 60 日経過後に再度試したところ移管できたと報告されています。
ただし、TLD（例：.com/.net と .nl など）やレジストラのポリシーによって条件が変わることがあるため、移管が弾かれたら「取得日・更新日・ロック状態」をまず確認してください。
authCode を取得する：App Service Domains の transfer out API
Azure ポータルの UI だけで完結しない場合でも、ドキュメントにある 「App Service Domains – transfer out」 の API から authCode を取得できることがあります。流れは次の通りです。
- Microsoft のドキュメントで「App Service Domains transfer out」を検索し、該当ページを開く
- ページ内の 「Try it」（試す）を選び、Azure アカウントでサインインする
- フォームで サブスクリプション、リソースグループ、ドメイン名（例：zoleaf.nl） を指定して実行する
- レスポンスに含まれる authCode を控える
返ってくる値は概ね次のようなイメージです（実際の値は伏せます）。
{
"authCode": "XXXXXXXXXXXX"
}この authCode が、移管先レジストラの「移管申請」フォームで求められるコードです。
移管先レジストラでの手続き
authCode を取得できたら、移管先（例：お名前.com、ムームードメインなど）で「他社からの移管」を開始します。一般的な流れは次の通りです。
- 移管先レジストラで「ドメイン移管（受け入れ）」を選ぶ
- 対象ドメイン（
zoleaf.nl）を入力 - authCode（EPPコード）を入力
- メール承認や支払いなど、レジストラの案内に従って完了させる
移管中の DNS については、基本的に「NS を切り替えない限り現状が維持」されます。とはいえ、レジストラごとに細部が異なるので、移管先の案内（移管中の DNS 取り扱い）を一度確認しておくと安心です。
落とし穴：authCode は取れたのに「ドメインがロックされています」と言われる
最近のケースとして、transfer out API で authCode は発行されたのに、移管先で申請すると「Domain is locked」等で弾かれることがあります。これは レジストラロックが解除されていないのが原因です。
通常のレジストラなら自分でロック解除できますが、App Service ドメインでは解除手段が提供されないことがあります。その場合は、Microsoft サポートにロック解除を依頼する必要があります。
問い合わせ時に伝えると話が早い情報を、表にまとめます。
| 伝える内容 | 例 | 理由 |
|---|---|---|
| 対象ドメイン | zoleaf.nl | 該当リソースの特定 |
| 購入経路 | App Service ドメインで購入 | 担当チームの切り分け |
| 現象 | transfer out API で authCode 取得済みだが移管がロックで失敗 | 解除依頼の主旨が明確になる |
| 必要な対応 | Registrar lock の解除（transfer out 可能状態にしてほしい） | 解決に直結する依頼になる |
移管完了後：ネームサーバーを Azure DNS の NS に変更する
移管が完了したら、いよいよ本来やりたかった「Azure DNS でのレコード管理」に移れます。作業はシンプルで、移管先レジストラの管理画面で ネームサーバー（NS）を Azure DNS の 4 つに置き換えるだけです。
Azure DNS の NS は「ゾーンごとに固有」
Azure DNS の NS は、例として次のような形式になります。
ns1-35.azure-dns.com.ns2-35.azure-dns.net.ns3-35.azure-dns.org.ns4-35.azure-dns.info.
ただし、この番号（例では 35）はゾーンによって異なります。必ず 自分の Azure DNS ゾーンの「NS レコード」に表示されている値を転記してください。
末尾の「.（ドット）」は付けたほうが安全
DNS の FQDN（完全修飾ドメイン名）としては末尾にドットを付けるのが正しい形式です。多くの管理画面は自動補完しますが、意図しない変換を避けるためにも、表示されている通りに入力するのが無難です。
Azure DNS 側でやること：ゾーン作成とレコード投入の実務
NS を切り替える前に、Azure DNS へ必要なレコードを用意しておきます。ここを雑にすると、切り替え直後にサイトやメールが止まります。
最低限のレコード棚卸し（Web/メールで分けて考える）
| 用途 | 代表レコード | 例 | 入れ忘れると |
|---|---|---|---|
| Webサイト | A / CNAME | @ の A、www の CNAME | Web が表示されない |
| 証明書・検証 | TXT | ドメイン所有権確認、ACME の検証 | 証明書更新や所有権確認が失敗 |
| メール | MX / TXT / CNAME | MX、SPF（TXT）、DKIM（CNAME/TXT）、DMARC（TXT） | メール送受信や到達率が悪化 |
| サブサービス | CNAME / SRV | Teams/Skype、各種 SaaS の接続 | 一部サービスだけ不通になり原因が追いづらい |
「今は Web だけだから A と CNAME だけでいい」と思っていても、実際には SaaS 連携や証明書、メール認証で TXT/CNAME を使っていることが多いです。現行 DNS の全レコードをエクスポートしてから移すのが安全です。
Azure DNS に入れる順番（おすすめ）
- 現行 DNS のレコードを一覧化（スクショでも良いが、可能なら CSV/テキストで残す）
- Azure DNS ゾーンを作成（ゾーン名は
zoleaf.nl） - Web に必要な A/CNAME、メールに必要な MX/TXT などを投入
- 切り替え前に、権威 DNS を指定して問い合わせて動作確認（後述）
- レジストラの NS を Azure DNS の NS に変更
切り替え後の確認：Azure DNS が参照されているかを判定する
NS を変えた後は「本当に Azure DNS が権威になったか」「レコードが正しく引けるか」を確認します。よくある誤解は、ブラウザで表示できたから OK と判断することです。ブラウザはキャッシュや CDN の影響を受けるため、DNS の状態確認には向きません。
まずは NS / SOA を見る
dig NS zoleaf.nl
dig SOA zoleaf.nl返ってくる NS が azure-dns 系になっていれば、委任は成功しています。SOA も Azure DNS のものに変わります。
「権威 DNS を指定して」レコードを引く
切り替え直後は、キャッシュの影響で外部 resolver が古い NS を掴んでいることがあります。そんなときは、Azure DNS の NS を直接指定して確認すると早いです（ns1-35 の部分は自分のゾーンの値に置き換えてください）。
dig @ns1-35.azure-dns.com zoleaf.nl A
dig @ns1-35.azure-dns.com www.zoleaf.nl CNAMEここで正しい値が返るなら、Azure DNS の中身は正しく、あとは浸透待ち（キャッシュ更新待ち）という切り分けができます。
よくあるハマりどころと回避策
Azure DNS に必要レコードを入れ忘れて切り替え、即障害
最も多い失敗です。特にメール関連（MX/SPF/DKIM/DMARC）は、気づかないうちに運用に組み込まれています。切り替え前に「レコード棚卸し表」を作り、入れた／入れてないをチェックしてください。
Azure DNS の NS を「推測」で入力してしまう
Azure DNS の NS はゾーンごとに変わります。ネット記事の例（ns1-xx）をそのまま使うのは危険です。必ず自分のゾーンに表示される NS を転記してください。
DNSSEC が有効なまま NS を変更してしまう
DNSSEC を使っている場合、レジストラ側には DS レコードが登録されています。NS を切り替えると署名が合わず、名前解決が失敗することがあります。DNSSEC を利用しているなら、移管・切り替えの前後で「DS をどう扱うか」を決め、必要なら一時的に無効化してから進めるのが安全です。
切り替え後の「反映待ち」を判断できず、不必要に設定をいじってしまう
DNS はキャッシュが絡むため、切り替え直後にクライアントの環境によって見え方が変わります。焦ってレコードを触る前に、次を確認すると落ち着いて判断できます。
- dig/nslookup で NS と SOA が Azure DNS になっているか
- Azure DNS の NS を指定して問い合わせたときに 正しいレコードが返るか
- 外部の複数 resolver で結果が揃ってくるか
どうしても移管が難しい場合の現実的な選択肢
事情があって「今は移管できない（取得直後で制限、社内手続き、支払いの都合など）」こともあります。その場合は次の方針を取ります。
- Microsoft サポートに依頼して NS 更新を代行してもらう（ただし自己解決より時間が読みにくい）
- 「詳細管理」が開けるようになるまで、App Service ドメイン側で DNS レコード管理できる範囲で運用し、移管できるタイミングで切り替える
ただし、今回の根本原因が「レジストラ相当の画面に入れない」なので、最終的に自分でコントロールできる状態へ移す（移管）が、長期的には最も安心です。
まとめ：App Service ドメインで NS が切り替わらないなら「移管」が確実
Azure の App Service ドメインは導入が簡単な反面、委任やロック解除などの重要操作が Azure 側の自動処理に依存します。今回のように 「Delegate to Azure DNS zone」を押しても NS が切り替わらない状況では、ユーザーがレジストラを直接操作できず、解決が難しくなります。
確実に Azure DNS で運用したいなら、transfer out API で authCode を取得 → 移管先レジストラで移管申請 →（必要ならサポートでロック解除）→ 移管後に NS を Azure DNS へ設定という流れが王道です。移管後は一般的なドメイン運用と同じになり、DNS 周りのトラブル耐性が一気に上がります。
コメント