😵

DNS設定事故ってしまったのでちゃんと調べてみました

2023/12/15に公開

事故った経緯

  • 新しいLPをサブドメインにてリリースすることになった
  • 公開直前に脳死でアナリティクスやサチコを入っておこうと
  • サチコの「DNS レコードでのドメイン所有権の確認」画面に従って、サブドメインのにTXTレコードを入れた
  • リリース作業完了!とのんびりしてたら、30分後サブドメインがDNS_PROBE_FINISHED_NXDOMAINで表示できなくなった。しかもプレスリリースすでに放出され、たくさんのいいねがついた状態
  • 絶対DNS設定のせいだ!と慌てて追加したTXTレコードを削除、こっそり直ってくれ!とリロードしたりDNSプロパゲーションチェックツールで伝搬状況を確認したりしているところで、「繋がらない!至急確認お願い!」とのslack通知が来た
  • なしすべもなく、待つこと30分
  • 幸い復旧されたが、この待つ30分間が長かった。そしてプレスリリース直後という重要な時間帯に、30分間繋がらなかったという事実で心が乱れたまま
  • ということでちゃんとDNSのことを調べてみました

DNS設定なぜ即座に反映されないか

「DNS伝播」と呼ばれるプロセスによって時間がかかる。
DNSプロトコルが世界中に分散したサーバーシステム上で動作し、新しい設定が全てのDNSサーバーに到達し、各サーバーのキャッシュが更新されるまでには時間がかかるわけ。

ISP(インターネットサービスプロバイダ)などの運営側はそれぞれのDNS更新頻度も違うし、DNSサーバーのキャッシュによって古い情報が維持されたり、DNSレコードのTTL(Time To Live)設定の秒数が切れるまで新しい情報は取得しにいかない、物理的にサーバーの地理的位置によっても、ユーザーごとで反映されるタイミングが違ったりするぐらい。

実際今回の場合、自分の環境でサブドメインが復活したときでも、他のメンバーが学内ネットワーク経由では相変わらず繋がらず、テザリングでやったら繋がったとのこと。そしてしばらく経つと、やっと学内ネットワークも繋がるようになった。

即座反映コマンドでもあったらいいけど、それはない。
(ぐぐったら「DNS 反映 コマンド」とあるが、あくまでDNSキャッシュを消すぐらいのことしかできない)

事故ったら、DNS設定直して、待つだけ。
直したDNS設定は本当に正しいかも再度反映されるまでわからない。
サーバー側のヘルプもDNS設定反映するのに数時間~24時間程度かかるとのことなので、リリース直前DNSいじるのはリスキーすぎる。。。

というわけで、待っているときは、宅急便を確認するみたいに、DNSプロパゲーションチェックツールで伝播状況を確認するぐらいしかできることはない。

例えばこんなツール。ぐぐれば一番上にでるやつ
https://www.nslookuptool.com/ja/
※ DNS反映まちのとき、日本はずっと❌なのになぜか中国とカナダがなぞに先に✅になってた。。。奥深い

TXTレコードそもそもなに?

TXTレコード(テキストレコード)は、DNS(ドメインネームシステム)における一種のレコードで、任意のテキスト情報をドメインに関連付けるために使用される。

主にサチコのようにドメイン所有権を確認する場合、メールの送信元を認証する場合(SPFレコード)などで使う。

通常、TXTレコードはルートドメイン(例えばsample.com)に対して設定するもの。サブドメイン(今回の場合、hoge.sample.com)に対してTXTレコードを設定したせいで、DNSが解決できずサブドメインが開けなくなった。

そもそも、サチコはドメインに対して設定することで、サブドメインも自動的にカバーされる。これは、ドメインレベルのプロパティ設定のメリットでもある。今回の場合、そもそもサチコに設定すべき対象はサブドメインではなくメインドメインだった。

参考:TXTレコードの主な用途
  1. ドメイン所有権の確認:

    • ウェブサービス(例えばGoogle Search Consoleや各種ウェブマスターツール)は、TXTレコードを使用してドメインの所有者を確認することがあります。所有者は特定のテキスト文字列(通常はサービスから提供される)を自分のドメインのDNS設定にTXTレコードとして追加します。この文字列を通じて、サービスはドメインの所有者がそのサービスを使用する権限を持っていることを確認します。
  2. SPF(Sender Policy Framework):

    • メールの送信ポリシーを定義するために使用されることが多いです。SPFレコードは、特定のドメインから送信されるメールの合法性を確認するために使われ、スパムやなりすましを防ぐのに役立ちます。
  3. DKIM(DomainKeys Identified Mail):

    • メールの認証に使用されるDKIMの公開キーを格納するために使われます。これにより、メールが改ざんされていないことを受信者が確認できます。
  4. DMARC(Domain-based Message Authentication, Reporting, and Conformance):

    • SPFとDKIMのポリシーを組み合わせ、メール認証の結果に基づいて行動を定義するために使用されます。

TXTレコードは非常に汎用性が高く、上記以外にも様々なカスタム用途に使用されることがあります。ただし、TXTレコードの設定は慎重に行う必要があり、特にドメインの所有権確認やメール認証システムにおいては、正確な設定が重要です。誤った設定はメールの配信問題やセキュリティリスクを引き起こす可能性があります。

また、同じドメインに対して、複数TXTレコードも基本的に設定可能。
ただメールの送信元を認証するために設定するSPFレコードは複数あるとよろしくない。

参考:SPFレコードとは

SPF(Sender Policy Framework)レコードはメールの送信元を認証するために使用される特定の種類のTXTレコードです。SPFは、ドメインから送信される電子メールが合法的なソースから来ていることを確認するためのメール認証手法の一つです。

SPFレコードは、ドメインのDNS設定に追加されるテキストレコードで、どのメールサーバーがそのドメイン名を使用してメールを送信することが許可されているかを定義します。メール受信サーバーは、受信したメールがSPFレコードで指定されたサーバーから送信されたものかどうかを確認し、それに基づいてメールの合法性を判断します。

SPFレコードの一般的な形式は次のようになります:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:example.com -all

この例では、192.0.2.0/24 および 198.51.100.0/24 のIPアドレス範囲からのメール送信が許可され、example.com で定義されたポリシーを含むことを示しています。そして -all は、これらの条件に合致しないメールはすべて拒否することを意味しています。

SPFレコードを使用する主な目的は、ドメイン名のなりすましやスパムメールの送信を防止することです。適切に設定されたSPFレコードは、メールの信頼性を向上させ、受信者が不正なメールを受け取るリスクを低減します。ただし、SPFレコードは正しく設定する必要があり、誤った設定は合法的なメールの配信を妨げる可能性があります。

CNAMEレコードで所有権確認もあるけど、どうちがう?

CNAMEレコード(Canonical Name Record)は、ドメインネームシステム(DNS)の一部で、一つのドメイン名(別名)を別のドメイン名(正規名)に関連付けるために使用するもの。
要はドメイン名のエイリアスを作成するときに使う。例えばwww.example.comexample.com にリダイレクトされるように設定する。

TXTレコードは基本ルートドメインに指定するものに対し、CNAMEレコードは基本サブドメインに設定するもの。

サチコは基本TXTレコードで所有権確認すればいいけど、特定のホスティングプロバイダーやドメイン登録サービスがTXTレコードの追加をサポートしていない場合のみ、代替手段としてCNAMEレコード使う。

あえてサブドメインで、サチコ(Google Search Console)に登録したい場合

「DNS レコードでのドメイン所有権の確認」ではなく、「URL プレフィックス」で下記のいずれの方法によって所有権が確認できる。

アナリティクス設定済み(gtag埋め込み済み)の場合は、即座で「所有権を自動確認しました」と設定完了...

なんだよ...

まとめ

  • リリース直前に下手にDNSレコードいじるな
  • TXTレコードはサブドメインに設定するな
  • 事故ったら設定直して、あとは反映されるのを待つしかない
  • ネットワークの基礎、ちゃんと勉強しよう

Discussion