Xserverを使っているお客様から、サブドメインで新たなウェブサイトを作りたい、というご依頼をいただき作業していた時の事です。
DNSレコードの設定をしていた時に、このようなメッセージがウェブブラウザー（Google Chrome）に表示されてウェブサイトにアクセスできなくなったのです。
「DNS_PROBE_POSSIBLE」
これはDNSで名前探索をしたときに応答が得られなかったときに出るメッセージです。
実際、 nslookup でAレコードで問い合わせても回答を得られず、その通りの意味なのですが。
問題はAレコードを触っていなかったということ。設定も一見正しい。
ということでその原因を調べてみた、というのが今回のお話です。
DNS_PROBE_POSSIBLE って何？
正直、私もこのメッセージを見て悩みました。
RFCを見ても載っていないからです。
おそらくGoogle Chrome が独自に出しているメッセージなんだろうと推測しています。
DNS Probe（プローブ）自体の意味は何となく推測できます。
Probe は診断、探査、探針という意味で、工業的には診断ツール的なものを指す場合が多いです。
なので、DNSプローブだったら、DNS（名前解決システム）がうまく働いていないのでその診断をしてみます、というニュアンスかな、と思っています。つまりGoogle Chrome（ブラウザー）がそういう取り組みを内部で行っているのかな、という推測です。
だとしたら、RFCには載る内容ではないので、Google Chrome 独自のメッセージというところで私個人的には納得してますが、識者のご意見もうかがいたいところです。
と、前置きはこの程度にして本題に移ります。
DNS_PROBE_POSSIBLE が出た原因について
一般論で言うと、いくつか考えうる原因はあります。
サーバーやドメインに関する初期設定段階で躓いている場合
- ネームサーバーレコードが登録されていないか間違って登録している
→ネームサーバーレコードを正しく登録しましょう - レコードは登録されているが、ネームサーバーまで到達していない
→NSレコード不備や、レジストラ上でネームサーバーを誤って登録している可能性あり
突然発生した場合
- ドメイン期限切れ
→レジストラに言ってすぐ再登録してもらう - ローカルネットワーク機器の不調
- →PCやローカルルーターやWifi、契約している回線の問題。再起動で直る場合も意外と多い。
- ネームサーバーは生きているが、ネームサーバーの指定が誤っている
→PCやローカルルーターやWifi‥ローカルDNSサーバーの設定ミス - ネームサーバーが死んでいる
→DNSサーバー障害で、プロバイダーに問い合わせてみる
結論から言うと「ネームサーバーレコードが登録されていないか間違って登録している」場合だったのですが、今回はちょっと事情が特殊でした。
タイトルにもある通り「ワイルドカード」を指定していたことが問題でした。
なのですが、その前に前提知識が無いとわけわかんないと思いますので。
以下の通り簡単に説明をしていきます。
DNS における ワイルドカード とは？
DNSレコードを登録するときに、ホスト名に「*」を指定することができます。
これをワイルドカードと呼びます。
余談ですが、ここでいうホスト名とは同一Zoneにおけるホスト名で、FQDNではありません。
厳密にはサブドメインとも違います。「ホスト名」とここでは呼びます。
一般的なDNSレコード（Aレコード）の書き方例
www IN A 192.168.0.1この場合、 www がホスト名で、Aレコードとして IPアドレス「192.168.0.1」を返します、という意味です。
別の例です。
ワイルドカードを指定するとこのような書き方になります。
* IN A 192.168.0.2この場合は、ホスト名が xxx だろうが yyyだろうが、何が来ても AレコードとしてIPアドレス「192.168.0.2」を返します、という意味です。
もちろん、 www というホスト名が明示されている場合は、そちらが優先されます。
ホスト名が明示されていない場合に、ワイルドカードで指定された内容が適用される、という使い方です。
Xserverではワイルドカードが指定される
ここはXserver特有の設定の話です。
Xserverでは「サブドメイン」という名称で、同一ドメインに対し、複数の（ウェブサイトにおける）バーチャルホスト（ウェブサイト）を設定することができます。
例えば、 www.en-pc.jp というコーポレートサイトがあったとして、それとは別に recruit.en-pc.jp という採用サイトを作る、ということができます（現実には採用サイトはありません😅）
その場合、XserverはDNSレコードを次のように設定します。
* IN A 202.226.39.150「ウェブサーバー」上ではバーチャルホストを設定するのですが、DNSレコード上はワイルドカードのままで、設定を変える事はしません。
Xserverでは、ホスト名が www であっても、 recruit であっても、同一ドメインであれば同じXserverのIPアドレスを割り振られます。サーバーが同じなので当たり前の話ですが。
そういう前提なのでワイルドカード指定にした方が都合がよいのでしょう。
もちろんこれは標準設定というだけであって、後から柔軟に変更することはできます。
特定のホストにTXTレコードを設定したら、DNS_PROBE_POSSIBLE が出た
上記前提のもと話を進めます。
今回、 recruit サイトの方でTXTレコードを追加する必要性が出てきました。
余談ですが、TXTレコードに追加した理由は、 Search Consoleでサイト所有者を確認するための認証テキストをいれるためです。
それだけの話でAレコードは一切触らないので、最初これでウェブサイトが表示されなくなった時はびっくりしました。なぜこれで？と。
改めて、DNS_PROBE_POSSIBLEが出た時のDNSレコードの状態を例示します。
* IN A 202.226.39.150
recruit IN TXT google-site-verification==XXXXXXXXXここまでの説明だと、 recruit というホスト名のAレコードは ワイルドカード指定されているから、202.226.39.150を返してくる、と思うでしょう？
でも、そうはなりませんでした。
DNS_PROBE_POSSIBLE が出た理由
正直、推測の域を出ませんが。
おそらくこういうことかな、と思っています。
- ワイルドカードが適用されるのは、問い合わせの対象となるホスト名が同一Zone内のレコードに一切存在しない場合だけ
- レコードタイプ（A、TXT、等）は関係なく、一つでもホスト名を指定された場合に、ワイルドカードは適用されなくなる
※同じこと２回書いてますが気にしないでね😅
今回の場合、TXTレコードに recruit というホスト名が追加されたことで、Aレコードにある ワイルドカードが適用されなくなった、と推測しています。
ワイルドカード指定時のDNS_PROBE_POSSIBLE を回避する方法
上の推測が正しいのだとしたら、答えは簡単ですね。
recruit というホスト名に対するAレコードを追加すればよい話です。
* IN A 202.226.39.150
recruit IN A 202.226.39.150
recruit IN TXT google-site-verification==XXXXXXXXXこういうことです。
ワイルドカードのレコードではなく、 recruit と明示されているレコードから値が返される事は明確です。
ワイルドカードは極力使用しない方が無難
正直、上の話はニッチなケースだろうと思います。
なので、解決方法を思いつく事が苦手な人（知識で解決したがる人）からすると、情報として例示しておいた方が良いと思い、今回書いた次第です。
ところで、ワイルドカードって便利なのです。
基本的にはどのようなホスト名で問い合わせても適用されるものなので、ホストが追加される都度DNSサーバーの設定変更をしなくて済みます。
上の例であれば、バーチャルホストを追加しさえすればよい話です。
DNSサーバーの設定を変えなくても済むので、作業手順が減り効率的です。
ただ、長く運用するという観点からみると、一考の必要があると思います。
運用を考えて設定方法を「設計」する事の重要性
今までに追加したホスト名を、システム上で知る術を考えてみましょう。
上の方法だと、ウェブサーバー上でしかどのようなホスト名があるのかを確認できない、ということがわかると思います。
DNSサーバー上だけを見ても、どういったホスト名が存在しているかを知ることが出来ません。
つまりDNSサーバーの設定を見る限りは、ホスト名を管理できていない、ということです。
ホスト名とIPアドレスを管理するのがDNSの中心的役割なのに、です。
そもそも今回の件は、DNSについて細かい仕様を知っていないと起きうる問題ですし、その解決についても知らなければ類推をし実証していく、という過程が必要となります。
運用上の問題も明確ですね。ホスト名の管理をシステム外で行う必要があります。
システム外というものが、上の例のようにバーチャルホスト、つまりウェブサーバー上の設定であればまだましです。同一サーバーにある設定を探せばよいわけですから、でもそれが「資料」だったり「人間の脳みそ」だったりするとやっかいです。いわゆる「人柱システム」の始まりです。
だから、冗長で面倒かもしれませんが、ワイルドカードは極力使わず、ホスト名を明示するようなDNSレコードの設定が管理面からみて良いだろう、と思っています。
情報はなるべく１か所、現場に集中させた方が良いという考えです。
もちろんバックアップの意味も考えてドキュメント化はしますよ。でもそれはあくまで緊急用。
少なくとも当社は運用を重視したポリシーで考えています。
なぜならシステムは作ってお終いではなく、作ってからが本番だから、です。
ウェブ制作会社さんへ
ここからはちょっとした宣伝。
ウェブ制作会社さんの助けになれないかな、と思ってのアナウンスです。
ウェブ制作を生業としている方々、特にデザインやライティング、コンテンツ制作など得意としているクリエイターさんにとって、ウェブにまつわる技術、特に今回の様なDNSやウェブサーバーといったことは切っても切れない関係にあると思います。
もちろん一般的な事であればみなさん自力で解決できるスキルはお持ちであろうと思います。
でも、今回ご紹介した事例のように、想定と異なる動きをしたときに悩まれているのだろうと思っています‥いや、実際に困って相談に乗られる事がままあるので、これは氷山の一角だと思っています。
そこで自力解決できるようにと、多方面でスキルを学ばれるのも一つの方法ではあると思いますが、一人で対応することの限界はどうしても出てくるだろうと思います。
とはいえ、いざという時に頼れる相手がいないと困るのも事実。
だからそういうときに、気軽に相談できるような関係値を築きたいと思い、ＩＴ相談役サービスを始めました。
初回相談は無料です。
だいたいそこで解決しますが、もしそこで価値を感じてもらい、今後のもしもの時の「保険」的な活用や、顧問弁護士のような安心材料をお考えであれば、ぜひ継続利用をご検討下さい。
当社としても、様々なジャンルのデザイナーさんと協業関係を組める形が出来ればベストだと思っています。
餅屋は餅屋、ぜひお互い手を取って活躍できる関係値を築いていきましょう！