## この記事でわかること

- DNS が「インターネットの電話帳」と呼ばれる理由
- 業務で名前を見かける主要レコード(A / MX / TXT / CNAME)の役割
- 設定変更時に必ず知っておきたい TTL と反映時間の考え方

## DNS は「ドメインを実体に変換する仕組み」

ホームページにアクセスするとき、ブラウザは `https://example.co.jp` のような **ドメイン名**を入力します。ところがインターネット上で実際に通信するには、サーバーの **IP アドレス**(例: `203.0.113.10`)が必要です。

DNS（Domain Name System、ドメインネームシステム）は、この「**ドメイン名を IP アドレスに変換する**」仕組みです。電話帳に載っている名前から電話番号を探すのとよく似ています。

メールも同じく、`info@example.co.jp` 宛にメールを送るとき、送信側のサーバーは「`example.co.jp` のメールサーバーはどこか」を DNS に問い合わせて配送先を決めます。

![DNS は名前を実体に変換する仕組み](/blog/dns-basics/dns-resolution.svg)

つまり DNS が止まると、

- ホームページが開かなくなる
- メールが届かなくなる
- 取引先のシステム連携(API)も止まる

という状態になります。サーバー本体は動いていても、DNS が壊れると外から見えなくなる、という構造です。

## 業務で目にする主要レコード

DNS には数十種類のレコードタイプがありますが、中小企業の業務で日常的に出てくるのは次の 4 種類です。それぞれの役割を理解しておけば、サーバー会社や制作会社とのやり取りで困ることはほぼありません。レコードの全体像は[DNSレコードの種類をわかりやすく解説](/blog/dns-record-types)も参考になります。

![主要 DNS レコードの役割](/blog/dns-basics/main-records.svg)

### A レコード

ドメインを **IPv4 アドレス**に紐づけるレコード。ホームページや Web アプリの公開に使います。`example.co.jp → 203.0.113.10` のようなマッピングです。サーバー移転時はここを書き換えます。

### MX レコード

そのドメイン宛のメールを **どのメールサーバーに届けるか** を指定するレコード。Google Workspace を使っているなら Google のメールサーバーを、Microsoft 365 なら Microsoft のサーバーを指定します。MX レコードの詳しい設定は[MX レコードの設定方法](/blog/mx-record-guide)で扱っています。

### TXT レコード

任意のテキストを置けるレコード。実用上は **メール認証(SPF / DKIM / DMARC)** や、ドメイン所有確認(Google Search Console や Microsoft 365 のドメイン認証)で使います。中小企業がメール到達率の改善に取り組む際、このレコードを触る機会が一番多いはずです。書ける文字数や複数値の扱いといった基本は[TXT レコードの基本](/blog/txt-record-basics)、メール認証の入口としての位置づけは[メール認証(SPF / DKIM / DMARC)とは](/blog/email-auth-basics)で取り上げています。

### CNAME レコード

別名(エイリアス)を作るレコード。`shop.example.co.jp` を `example.myshopify.com` などの SaaS のホスト名に向ける、といった使い方をします。**A レコードと同じ階層には併存できない**という制約があり、これを知らずに設定してメールが止まる事故が起きやすい論点です。`shop.` `mail.` のような **サブドメイン** をどう設計するかは[サブドメインとメール運用の基本](/blog/subdomain-basics-mail)に整理しています。

なお A / MX / TXT / CNAME を実際に登録するのは、ドメインに紐づいた **ネームサーバー** です。「ドメイン管理会社」と「ネームサーバーの管理画面」が別になっているケースは中小企業で非常に多く、設定変更時の混乱の元になります。役割分担と確認方法は[ネームサーバーとは(Web 担当者向け入門)](/blog/nameserver-basics-smb)を参照してください。

## TTL と「反映に時間がかかる」の正体

DNS 変更後によく聞く「**反映に最大 24〜48 時間かかります**」という説明、これには理由があります。

DNS 情報は世界中の **キャッシュサーバー**に一時保存されており、毎回大元に問い合わせるわけではありません。各レコードには **TTL(Time to Live)** という値が設定されていて、たとえば `3600`(秒)なら「1 時間はキャッシュを使ってよい」という意味になります。

![DNS 変更が反映されるまでの流れ](/blog/dns-basics/ttl-propagation.svg)

つまり変更直後でも、世界各地のキャッシュサーバーは旧情報を持ち続け、TTL の時間が経過してから新しい情報を取りに来ます。サーバー移転やメール基盤切り替えなど、計画的な変更では **事前に TTL を短くしておく(例: 86400 → 300)** のが定石です。

ただし TTL を短くしすぎると DNS サーバーへの問い合わせが増え、応答性能に影響することもあります。**普段は 3600〜86400 秒、変更前 1〜2 日だけ 300 秒**、というふうに使い分けるのが無理のないバランスです。

## やってしまいがちな 3 つのミス

DNS は仕組みがシンプルな反面、誤操作の影響範囲が広く、メール停止やサイト 404 に直結します。中小企業で実際に起きやすいのは次の 3 パターンです。

1. **過去の制作会社が設定したレコードを把握せずに上書き**: SPF や DKIM など、メール認証用の TXT レコードを誤って消してしまうと、Gmail への配信性が一気に悪化します
2. **MX レコードを 1 つだけしか設定しない**: メールサーバーの冗長化のため、通常は優先度違いで複数の MX を持ちます
3. **A レコードと CNAME を同じホスト名に併設**: 仕様違反で、リゾルバによっては解決失敗になります

このうち 1 番のケースは、DMARC 義務化以降のメール到達率低下の主原因のひとつです。詳しくは[Gmailにメールが届かない時の原因](/blog/gmail-not-receiving)で解説しています。

## まずは自社の DNS を可視化する

要点をおさらいします。

- DNS は「ドメイン名 → 実体(IP / メールサーバー)」を変換する仕組みで、止まるとサイトもメールも見えなくなる
- 中小企業で関わるレコードは A / MX / TXT / CNAME の 4 種類が中心。CNAME と A の併存制約だけは要注意
- TTL の存在で変更には反映時間が伴う。計画的な変更では事前に TTL を短くしておく
- DNS 改ざんを検知する仕組みとして [DNSSEC](/blog/dnssec-basics) もあわせて知っておくと、レジストラ選定時の比較軸が増えます

「自社のドメインに今どんなレコードが入っているか分からない」「過去の制作会社が設定した TXT レコードが残っているか不安」、そんな場合は、まず無料の[ドメイン診断](/diagnose)で現状を可視化できます。SPF / DKIM / DMARC を含む主要レコードの設定状態を一括でチェックします。

設定変更を伴う作業を専門家に任せたい方は、お気軽にご相談ください。設定前後の動作確認まで人の手で確認しながら進めます。