新しい
広告が嫌いですか? 行く 広告なし 今日
開発者向けDNSレコード — A、CNAME、MX、TXT、そして48時間待つTTL
更新日
DNSレコードタイプの実用的な解説 — A、CNAME、MX、TXT、SPF、TTL — 開発者がデプロイやドメイン移行中に遭遇するよくある問題を紹介します。
広告 削除する？
ドメインを購入し、そこに何かを指し示し、今、ブラウザが古いサイトを表示していることに気づいた。あるいは、MXレコードを誤って設定し、メールがリジェクトされる現象に気づいた。DNSは開発者がほとんど無視するもので、問題が起きたときにはフィードバックループが遅く、痛みを伴う。
これはDNSについて聞いたことがない人向けのチュートリアルではなく、ドメインの概念を理解しているが、6ヶ月以上触れていない記録タイプを追加するたびにStack Overflowを参照する開発者向けのリファレンスです。
DNSが実際にどのように機能するか（30秒版）
ブラウザが解決するとき example.com、再帰的なリゾルバー（通常はISPまたは8.8.8.8）に質問する。リゾルバーがキャッシュを確認し、キャッシュヒットがあればキャッシュされた答えを返す。ヒットがない場合は、DNSツリーを上に進み、ルート名サーバー → TLD名サーバー（.com） → あなたのドメインの権限名サーバーへ進み、TTLが指定した期間だけキャッシュする。
すべてのDNSレコードはタイプ、名前、値、TTLを持ちます。それだけです。複雑さは、どのタイプが何を実行するかを理解し、レコードが非自明な方法で相互作用するかを知ることにあります。
実際に使うレコードタイプ
Aレコード — ホスト名へのIPアドレス
ホスト名をIPv4アドレスにマッピングします。これは最もよく使うレコードです。
example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN A 93.184.216.34問題点：同じホスト名に対して複数のAレコードを持つことができます。DNSはすべてのアドレスを返し、クライアントが1つを選択（通常はローリン）します。これは単純な負荷分散設定ですが、そのIPがダウンした場合、DNSはヘルスチェックを持たず、破損したIPを提供し続けます。TTLが終了するまで。
IPv6の場合、その対応は AAAAレコードです。同じ概念ですが、128ビットアドレスに変わります。
CNAMEレコード — 他のホスト名へのエイリアス
1つのホスト名を別のホスト名（IPアドレスではない）に指す。リゾルバーはチェーンを追って、Aレコードに到達するまで進みます。
www.example.com. 300 IN CNAME example.com.
blog.example.com. 300 IN CNAME mysite.netlify.app.CNAMEとA — どちらを使うべきか： サービスがホスト名を提供する場合（Netlify、Vercel、GitHub Pages、Heroku、ほとんどのCDN）はCNAMEを使用します。静的IPを持つ場合はAレコードを使用します。シンプルです。
厳しいルール： ゾーンの頂点（ドメイン名の基本形 — ）にCNAMEを設定することはできません example.com、ではなく www.example.com。RFC 1034では、頂点にはSOAおよびNSレコードが必要であり、同じ名前のCNAMEが衝突するため禁止されています。NetlifyやVercelがルートドメインにCNAMEを追加するように言う場合、実際にはそのDNSプロバイダーがANAMEまたはALIASレコードをサポートしていることを意味しています。これはCNAMEに似た動作をし、ゾーンレベルでAレコードに解決します。
また： CNAMEをCNAMEに直接参照しないでください 。技術的には合法ですが、各チェーンのホップは追加のDNSリクエストを引き起こします。さらに重要なのは、中間のCNAMEが破損した場合、あなたのレコードも破損します。
MXレコード — 電子メールのルーティング
他のメールサーバーにあなたのドメインのメールを配信する場所を示します。MXレコードには優先順位番号があり、数字が小さいほど優先度が高い。
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.mail1が利用不可の場合、送信サーバーはmail2に移行します。これは適切なフォールバックであり、負荷分散ではなく、優先順位の順番を指定しているだけです。
開発者が間違えること：IPアドレスまたはCNAMEにMXを指す。 MXの値はAレコード（ホスト名）にしか指し示せません（IPアドレスまたはCNAMEは不可）。 一部のDNSプロバイダーは、この誤設定を警告せずに保存し、その結果、メールが静かに失敗します。
Google WorkspaceまたはMicrosoft 365を設定する場合、それらはMXレコードのセットを提供します。優先順位番号を変更して賢いと誤解しないでください。メールルーティングの論理はそれらが正確である必要があります。
TXTレコード — 任意のテキスト、主に検証およびメール認証用
TXTレコードは自由形式のテキストを保持します。実際には、以下の3つの用途に使われます：
- ドメイン検証 — Google Search Console、Stripe、GitHub、および他の100以上のサービスが、ドメインを所有していることを証明するためにTXTレコードを追加するよう要求します
- SPF（送信ポリシーフレームワーク） — あなたのドメインからメールを送信できるメールサーバーを指定します
- DKIMおよびDMARC — スポーフィングを防ぐためのメール認証レコード
SPFレコードはこう見えます：
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"これはこう言っています：GoogleおよびSendGridはこのドメインからメールを送信できると許可されています；それ以外のものは疑念を抱かれるべきです（~all = ソフト失敗、 -all = ハード失敗）。
DMARCレコードは _dmarc.example.com:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"に存在します。 重要なことは： 1つのドメインに対してSPF TXTレコードを1つだけ持つことができます。 v=spf1 include:_spf.google.com include:sendgrid.net ~all.
新しいサービスが指示した場合に2つを追加すると、両方のレコードが存在し、メールサーバーが競合するポリシーを認識し、メール認証が破綻します。それらを統合してください：
NSレコード — 名前サーバーの委任
あなたのドメインの権限名サーバーを指定します。通常、これはドメイン登録者で設定され、DNSゾーン内で直接設定されません。DNSプロバイダーから別のプロバイダー（例：GoDaddyの名サーバーからCloudflare）に移行する場合、登録者レベルでNSレコードを更新します。
TTL — あなたが48時間待つ原因
TTL（Time To Live）は秒単位の数値です。キャッシュされたリゾルバーが答えを記憶する期間を示し、300秒は5分、172800秒は48時間です。
DNSレコードを変更したとき、古い答えはキャッシュされていて、最大 古いTTLまで記憶されます。Aレコードが48時間のTTLを持っていて、IPを変更した場合、一部のユーザーは2日間古いサーバーにアクセスする可能性があります。変更が行われた後、それに対して何もできません。
解決策は、変更を行う前にTTLを下げることです。計画された移行の標準的な手順：
- 移行48時間前までにTTLを300（5分）に下げます — 旧TTLが終了するまで待つ必要があります
- DNS変更を実行
- 5～10分間のプロパゲーションを待つ
- 新しい設定が正常に動作することを確認した後、TTLを3600～86400（5分～24時間）の適切な値に戻す
ステップ1を忘れて、ステップ2に直ちに進んで高TTLを使用した場合、あなたは困ります。TTLを下げることはできますが 今、しかしそれはまだキャッシュされていないリゾルバーだけの待機時間を短縮するだけです。すでにキャッシュされたレコードは元のTTLを待つ必要があります。
簡易リファレンス
| レコード | ポイント | パーセントエンコードされる必要があります | 注意点 |
|---|---|---|---|
| あ | IPv4アドレス | ホスト名 → サーバーIP | ヘルスチェックなし — ブレイクしたIPはTTLが終了するまで回転され続けます |
| – IPv6の場合も同様です | IPv6アドレス | ホスト名 → IPv6サーバー | Aレコードとともに追加を忘れることが、ダブルスタックサポートを容易にできない原因になります |
| – 別のドメインを指すエイリアス | 別のホスト名 | エイリアス、CDN/PaaSルーティング | ゾーンの頂点では使用できません；MX/NSはCNAMEに指し示せません |
| – メール交換レコード（メールがどこへ行くか） | ホスト名（Aレコード） | メール配信ルーティング | 値はホスト名でなければならず、IPまたはCNAMEに指し示せません；優先順位番号は重要です |
| – 検証レコード、SPF、DKIM、すべてのメール認証関連のものです | 自由形式のテキスト | SPF、DKIM、DMARC、ドメイン検証 | 1つのドメインに対してSPFレコードを1つだけ許可されています — 追加するのではなく、統合してください |
| – ドメインに対して権威のあるネームサーバー | 名前サーバーのホスト名 | DNS委任 | 変更は登録者レベルで行われ、プロパゲーションが遅い |
| CAA | CAドメイン | あなたのドメインに対してSSL証明書を発行できるCAを指定します | 誤設定により、証明書の更新をロックしてしまう可能性があります |
時間を節約するための項目
プレビューするには dig 直接、ウェブツールではなく。 dig @8.8.8.8 example.com A ローカルリゾルバーを回避し、GoogleのDNSが見ている内容を正確に表示します。Aの答えだけを追加します。 +short フル解決チェーンを確認するには +trace を追加します。
# Check what Google sees right now
dig @8.8.8.8 example.com A +short
# Check MX records
dig @8.8.8.8 example.com MX
# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT
# Full resolution trace
dig @8.8.8.8 example.com A +trace移行前にTTLを確認します。 でWindows上で dig example.com A および、答えセクションの3列目の数値を見てください。それが、TTLを下げずに現在のレコードを変更した場合に、あなたが待つ可能性のある時間（秒単位）です。
Cloudflareのプロキシレコードは、あなたの実際のIPを非表示にします。 Cloudflareのオレンジクラウドをレコードに有効にすると、世界に公開されるAレコードはCloudflareのIPであり、あなたのサーバーのIPではありません。これは通常、DDoS保護のために望ましいですが、これにより dig あなたのサーバーの実際のIPが表示されず、直接IPをプローブするツールは期待通りに動作しません。
広告なしで楽しみたいですか?
今すぐ広告なしで
恵 スコアボードが到着しました！
スコアボード ゲームを追跡する楽しい方法です。すべてのデータはブラウザに保存されます。さらに多くの機能がまもなく登場します！
広告 削除する？
必見ツール
すべて表示広告 削除する？
参加する
価値ある無料ツールの提供を継続するためにご協力ください
広告 削除する？