Azure App Serviceに独自ドメインを設定するとき、「DNSレコードは追加したのにValidateで通らない」「ドメインは追加できたのにHTTPSで警告が出る」といった状況になることがあります。
このとき最初に確認したいのは、A・CNAMEレコードとTXTレコードは役割が違うという点です。AやCNAMEは「そのドメインへのアクセスをどこへ送るか」を指定し、TXTは主に「そのドメインを自分が管理していること」をApp Serviceに確認させるために使います。
さらに、独自ドメインの登録・検証とHTTPS証明書のバインドも別の処理です。そのため、DNS設定が正しくても証明書がバインドされていなければHTTPSでは警告が出ます。逆に、TXTによる所有確認だけ成功しても、Webアクセス先を決めるAやCNAMEが完成しているとは限りません。
App Serviceの独自ドメインが検証できないときのA・CNAME・TXT確認
Azure App Serviceのカスタムドメイン設定では、まず各DNSレコードの役割を分けて考えると原因を切り分けやすくなります。
| レコード | 主な役割 | 代表的な用途 |
|---|---|---|
| A | ドメインをIPアドレスへ向ける | ルートドメイン |
| CNAME | ドメインを別のホスト名へ向ける | wwwなどのサブドメイン |
| TXT | ドメイン所有権を確認する | asuidによる検証 |
Microsoft Learnでは、ルートドメインではAレコード、サブドメインではCNAMEレコードが推奨されています。サブドメインをAレコードで設定することもできますが、CNAMEならApp Serviceの既定ホスト名を参照できるため、IPアドレスの変更に影響されにくいという利点があります。
重要なのは、TXTを登録したからAやCNAMEが不要になるわけではないことです。
最初にAzureポータルに表示された値を確認する
DNS事業者の管理画面を先に編集するのではなく、まずApp Service側で必要なレコードを確認します。
Azureポータルで対象のApp Serviceを開き、Custom domainsからAdd custom domainへ進み、追加したいドメイン名を指定します。
ここでいきなりValidateを実行するのではなく、Domain validationに表示されるDNSレコードの種類、ホスト名、値を確認します。
Microsoftの手順でも、App Serviceの画面に表示された値をDNS事業者側へ登録してからValidateする流れになっています。
特に次の値を推測して入力しないことが重要です。
- App Serviceへ向けるIPアドレス
- CNAMEの宛先
- TXTレコードへ設定するDomain verification ID
これらは自分のApp Serviceに表示された値をそのまま使用します。
DNS事業者によって「ホスト」「名前」「Name」「Value」「データ」など入力欄の名称は異なります。画面上の表記だけで判断せず、どの欄がレコード名で、どの欄が値なのかを確認してください。
ルートドメインではAとasuidのTXTを設定する
example.comのようにwwwなどが付かないドメインはルートドメインです。
Microsoft Learnで示されている基本構成は次のとおりです。
| 種類 | ホスト名 | 値 |
|---|---|---|
| A | @ | App Serviceの追加画面に表示されたIPアドレス |
| TXT | asuid | App Serviceに表示されたDomain verification ID |
Aレコードは実際の通信先をApp Serviceへ向けるための設定です。
一方、asuidのTXTレコードはApp Serviceがドメインの所有権を確認するために使用します。
たとえばDNS管理画面に次のような項目が表示されていても、IPアドレスやTXTの値はこの記事の例をコピーするのではなく、Azureポータルに表示された値を使います。
A
ホスト: @
値: Azureポータルに表示されたIPアドレス
TXT
ホスト: asuid
値: Azureポータルに表示されたDomain verification IDなお、DNSサービスによってはルートドメインを@ではなく空欄などで表現する場合があります。入力方式は利用しているDNS事業者の仕様を確認してください。
wwwなどのサブドメインではCNAMEとasuid.サブドメインを確認する
www.example.comのようなサブドメインでは、CNAMEを使用する構成が基本です。
wwwを追加する場合の考え方は次のようになります。
| 種類 | ホスト名 | 値 |
|---|---|---|
| CNAME | www | Azureポータルで指定されたApp Service側のホスト名 |
| TXT | asuid.www | Azureポータルに表示されたDomain verification ID |
Microsoft Learnでは、サブドメインのCNAMEと、それに対応するasuid.<subdomain>のTXTを作成する方法が示されています。
設定イメージは次のとおりです。
CNAME
ホスト: www
値: Azureポータルに表示された宛先
TXT
ホスト: asuid.www
値: Azureポータルに表示されたDomain verification IDここでも、CNAMEの宛先を他のWebサイトの例から推測しないことが大切です。
App Serviceの構成によって表示される値が異なる可能性があるため、Add custom domain画面に表示された現在の値を基準に設定してください。
DNSを保存したらApp ServiceでValidateする
必要なDNSレコードを登録したら、DNS事業者側で設定を保存します。
DNSサービスによってはレコードを入力しただけでは変更が確定せず、別途保存操作が必要になる場合があります。Microsoft Learnでも、DNS事業者によって管理画面や保存方法が異なることが案内されています。
保存後、AzureポータルのAdd custom domain画面へ戻ってValidateを実行します。
AまたはCNAMEとTXTの両方が正しく認識されれば、ドメイン追加へ進めます。
ここで注意したいのが、Validateに成功したことと、DNSによるアクセス先の切り替えが完了したことは同じではないという点です。
Microsoft Learnでは、TXTレコードだけを設定し、AまたはCNAMEをまだ設定していない場合でも、App Serviceがドメイン移行のシナリオとして扱い、検証自体は成功する場合があると説明されています。この場合、DNSレコードの横には通常の緑色チェックが表示されないことがあります。
つまり、
TXTによる所有確認成功
↓
独自ドメインを登録できる
となっていても、
利用者のアクセス
↓
AまたはCNAME
↓
App Serviceまで完成しているとは限りません。
「Validateが通ったからDNS設定は全部正しい」と判断しないことがポイントです。
稼働中サイトではA・CNAMEを安易に上書きしない
既存サイトをAzure App Serviceへ移行している場合は、さらに注意が必要です。
AやCNAMEは実際のアクセス先を決めるレコードです。そのため、現在運用しているWebサーバーを指しているレコードをApp Service向けに変更すれば、利用者のアクセス先そのものが切り替わります。
一方、TXTは所有確認に使用できます。
この性質を利用すれば、既存サイトへのアクセス先を維持した状態で、先にApp Service側のドメイン所有確認を進められる場合があります。Microsoft Learnでも、TXTだけを設定した状態をドメイン移行のシナリオとして扱えることが示されています。
本番サイトを移行するときは、
- 現在のA・CNAMEがどこを向いているか確認する
- App Serviceが要求するTXTを確認する
- 必要な所有確認を行う
- 新環境の準備状況を確認する
- 計画したタイミングでA・CNAMEを切り替える
というように、所有確認とアクセス先変更を別作業として扱う方が安全です。
既存のAやCNAMEを、意味を確認せずApp Service向けの値へ上書きするのは避けてください。
TXTは「検証できたから削除」で考えない
asuidのTXTは単なる一時的な確認コードとして扱わない方が安全です。
Microsoftは、このTXTレコードをドメイン検証IDとして使用しており、他のApp Serviceアプリによるサブドメイン乗っ取りを防ぐ対策として追加することを強く推奨しています。
そのため、
App Serviceへの追加が終わったからTXTはもう不要
と判断して、理由なく削除するのは避けましょう。
Webサイトへアクセスできるかどうかだけを見るとAやCNAMEしか使っていないように見えますが、TXTにはアクセス先とは別のセキュリティ上の役割があります。
独自ドメイン追加後の「No binding」はDNSとは別の問題
独自ドメインを追加できても、App Serviceのカスタムドメイン一覧で赤い×印とNo bindingが表示されることがあります。
これは、DNSが必ず間違っているという意味ではありません。
ここからはTLS/SSL証明書とHTTPSバインドの段階です。
Microsoft Learnでは、カスタムドメイン追加後に証明書のバインドが設定されていなければ、ブラウザからHTTPSでアクセスした際にエラーまたは警告が表示されると説明しています。
設定全体を分解すると次のようになります。
| 段階 | 目的 |
|---|---|
| A・CNAME | アクセスをApp Serviceへ向ける |
| TXT | ドメイン所有権を確認する |
| Validate | DNS設定をApp Service側で検証する |
| Add custom domain | 独自ドメインをApp Serviceへ登録する |
| 証明書 | HTTPS通信で使用する証明書を用意する |
| TLS/SSLバインド | 独自ドメインと証明書を関連付ける |
この順番を意識すると、「DNSは直したのにHTTPS警告が消えない」という混乱を避けやすくなります。
App Service Managed Certificateを選んだ場合も状態を確認する
独自ドメイン追加時にApp Service Managed Certificateを選択した場合、ドメイン追加後にApp Serviceが証明書を作成します。
Microsoft Learnでは、処理が完了するとNo bindingの状態からSecuredへ変わることが案内されています。
一方、Add certificate laterを選択した場合は、証明書を追加し、さらに対象ドメインへバインドする作業が必要です。
したがってHTTPS警告が出たときは、DNSを何度も書き換える前に、
- カスタムドメイン自体は追加済みか
- 証明書が用意されているか
- 対象ドメインに証明書がバインドされているか
No bindingになっていないか
を確認してください。
DNS設定とTLS設定を同じ問題として扱わないことが、トラブル解決の近道です。
「DNSは合っているはずなのに開けない」ときの確認ポイント
設定後に独自ドメインへアクセスできない場合は、症状によって確認箇所を変えます。
| 症状 | 優先して確認する項目 |
|---|---|
| Validateできない | TXT、A、CNAMEの名前と値 |
| Validateは成功するがサイトへ到達しない | AまたはCNAME |
| 独自ドメインは追加できたがNo binding | 証明書・TLSバインド |
| HTTPでは開けるがHTTPSで警告 | 証明書・TLSバインド |
| 以前のIPへアクセスしているように見える | DNSキャッシュ |
| 本番サイトが突然Azureへ切り替わった | 既存A・CNAMEを変更していないか |
Microsoft Learnでは、古いIPアドレスがクライアント側にキャッシュされている場合、Windowsなら次のコマンドでDNSキャッシュをクリアして再確認する方法も案内されています。
ipconfig /flushdnsただし、この操作はDNSサーバー上のレコードを変更するものではありません。DNS事業者側の設定が間違っている場合は、元のレコード設定を修正する必要があります。
App Serviceのカスタムドメイン設定で失敗しやすいポイント
特に多いのは、複数の設定を一つの作業だと考えてしまうケースです。
TXTだけ設定して完了したと思う
TXTは所有確認用です。
検証が成功しても、AまたはCNAMEがApp Serviceへ向いていなければ、通常のアクセス経路は完成していません。
AやCNAMEだけ設定してTXTを軽視する
アクセス自体が成立する場合でも、TXTにはドメイン所有確認やサブドメイン乗っ取り対策としての意味があります。
App Serviceに表示された検証用TXTも確認してください。
Validate成功とHTTPS成功を同じものだと思う
ValidateはDNSとドメイン所有確認の段階です。
HTTPSではさらに証明書とTLS/SSLバインドが必要です。
No bindingを見てDNSを変更する
No bindingが表示されている場合、まず証明書とバインドを確認します。
DNSを変更すると、正常だった名前解決まで壊してしまう可能性があります。
稼働中サイトのA・CNAMEをそのまま上書きする
A・CNAMEの変更はアクセス先の変更です。
既存サイトから移行している場合は、TXTによる所有確認と本番トラフィックの切り替えを分けて計画してください。
まず「どの段階で止まっているか」を切り分ける
Azure App Serviceで独自ドメインを追加できない、またはHTTPSで警告が出る場合は、DNSレコードを何度も変更するのではなく、次の順番で確認すると原因を特定しやすくなります。
Add custom domainに表示されたレコード名と値を確認する- ルートドメインならAと
asuidのTXTを確認する - サブドメインならCNAMEと
asuid.<subdomain>のTXTを確認する - DNS事業者側で保存を完了する
- App ServiceでValidateする
- 独自ドメインを追加する
- 証明書とTLS/SSLバインドを確認する
- HTTPSでアクセスを確認する
ポイントは、DNSの宛先設定、所有確認、独自ドメイン登録、HTTPS化を4つの別工程として見ることです。
「Validateできない」ならまずDNS設定を確認し、「No binding」やHTTPS警告なら証明書側を確認します。
この切り分けができれば、A・CNAME・TXTを手当たり次第に変更する必要はありません。まずAzureポータルのAdd custom domain画面を開き、現在要求されているレコード名と値を一つずつDNS事業者側の設定と照合するところから始めてください。
コメント