DNS管理の基礎｜中小企業の情シスが押さえるべき設定とトラブル対策
DNSとは「インターネットの電話帳」
DNS（Domain Name System）は、ドメイン名（josis365.com等）をIPアドレス（数字の羅列）に変換する仕組みです。Webサイトの表示やメールの送受信など、インターネット上のあらゆる通信がDNSに依存しています。
DNSの設定ミスは「サイトが表示されない」「メールが届かない」といった重大なトラブルに直結するため、情シス担当者が基本を理解しておくべき領域です。
そして厄介なことに、DNSのトラブルは影響が全社に及び、かつ自社では復旧できない待ち時間が発生します。 サーバーの再起動のように「対応すれば直る」性質のものではないため、事前の理解と慎重な作業手順が特に重要になる領域です。
情シスが管理すべきDNSレコード
Aレコード / CNAMEレコード
Aレコードはドメイン名をIPアドレスに紐づけるレコードで、Webサイトの公開に必須です。CNAMEレコードは別のドメイン名へのエイリアスで、Azure Static Web AppsやAWSのCloudFrontなどクラウドサービスの設定でよく使います。
MXレコード
メールの配送先を指定するレコードです。M365やGWSのメールを使う場合、MXレコードが正しく設定されていないとメールが届きません。
MXレコードには優先度（数値）があり、小さい値が優先されます。 M365やGWSへ移行した際、旧メールサーバーのMXレコードを消し忘れると、一部のメールが旧サーバーへ配送され続けます。移行後しばらくして「一部の相手からのメールだけ届かない」という症状が出たら、まずMXレコードの残骸を疑ってください。
SPF / DKIM / DMARCレコード
メール認証に使われるDNSレコードです。これらが適切に設定されていないと、自社ドメインからのメールが迷惑メールに分類されたり、なりすましメールを防止できなくなります。SPFはTXTレコードで送信元IPを宣言、DKIMは電子署名、DMARCは認証失敗時のポリシーを定義します。
3つの関係を整理すると次のようになります。
| レコード | 役割 | 未設定時のリスク |
|---|---|---|
| SPF | このドメインのメールを送ってよいサーバーを宣言する | 迷惑メール判定されやすくなる |
| DKIM | メールに電子署名を付け、改ざんされていないことを示す | 同上。認証の強度が下がる |
| DMARC | SPF/DKIMに失敗したメールの扱いを指示し、レポートを受け取る | なりすましを検知・防止できない |
DMARCは「p=none（監視のみ）」から始めてください。 いきなり p=reject にすると、メール配信サービスや業務システムから送っている正規のメールが受信側で拒否されます。まず監視モードでレポートを集め、自社ドメインを名乗って送信している経路をすべて洗い出してから段階的に強化します。
TXTレコード
ドメインの所有権確認（M365やGWSの設定時）、SPFレコード、その他のサービス検証に使用されます。
CAAレコード（設定しておくとよい）
どの認証局がこのドメインの証明書を発行してよいかを宣言するレコードです。設定しておくと、第三者が勝手に自社ドメインの証明書を取得することを防げます。必須ではありませんが、1行追加するだけで不正な証明書発行のリスクを下げられます。
よくあるDNSトラブルと対策
メールが届かない・迷惑メールになる
MXレコードの設定ミス、SPFレコードの構文エラーが主な原因です。SPFレコードは1つのドメインに1つだけ設定する必要があり、複数のSPFレコードを作ると認証が失敗します。複数のメールサービスを使っている場合は、1つのSPFレコードに「include:」で統合してください。
もう一つ多いのがSPFの「10回ルール」です。 SPFレコードの評価時に参照できるDNSクエリは10回までと決まっており、include: を並べすぎると上限を超えて認証が失敗します。M365、メール配信サービス、問い合わせフォーム、勤怠システム…と追加していくと、意外に早く到達します。上限が近い場合は、使っていないサービスの include: を削除するか、SPFフラット化のサービスを検討してください。
Webサイトが表示されない
Aレコード/CNAMEレコードの設定ミス、またはDNSの浸透（プロパゲーション）待ちが原因です。DNSの変更は反映まで最大48時間かかる場合があるため、切り替え作業は余裕のあるスケジュールで実施してください。
「自分の環境では見えるが、他の人は見えない」という状況はDNSキャッシュが原因です。 慌てて設定を変更し直すと、かえって状況が悪化します。まず外部のDNS確認サービスや、nslookup 8.8.8.8 のようにパブリックDNSを明示して問い合わせ、実際にどう返っているかを確認してください。
ネームサーバーの変更トラブル
ドメインのネームサーバーを変更する際、旧ネームサーバーのレコードを新ネームサーバーにコピーしてから切り替えてください。コピーせずに切り替えると、サイトやメールが一時的に利用不能になります。
これはDNS作業の中で最も事故が起きやすい操作です。 ネームサーバーを切り替えた瞬間、旧サーバーにあったレコードは一切参照されなくなります。「Webサイトのことだけ考えて切り替えたら、メールが全断した」という事故は実際に起きています。切り替え前に、旧ネームサーバーの全レコードをエクスポートして保管してください。
ドメインの有効期限切れ
技術的なミスではありませんが、実害が最も大きいトラブルです。有効期限が切れると、Webサイトもメールも同時に停止します。
- 自動更新を有効にする
- 登録メールアドレスを退職者個人のものにしない（共有メールボックスにする）
- 支払いカードの有効期限切れに注意する — 自動更新でも決済に失敗すれば更新されません
- 有効期限をIT資産台帳に記載する
「担当者が退職し、更新通知が誰にも届かないまま失効した」という事故は珍しくありません。
DNS管理のベストプラクティス
DNS設定のドキュメント化として、すべてのDNSレコードを台帳に記録してください。誰が、いつ、なぜ変更したかを追跡できるようにします。
TTL（Time to Live）の理解として、TTLはDNSレコードのキャッシュ時間です。変更予定がある場合は事前にTTLを短く（300秒程度に）しておくと、変更の反映が早くなります。
ネームサーバーの冗長化として、プライマリとセカンダリの2つ以上のネームサーバーを設定してください。ドメイン登録サービス（お名前.com等）を使っていれば、通常は自動で冗長化されています。
変更作業の手順を決めておく
DNS変更は「戻すのに時間がかかる」操作です。次の手順を標準にしてください。
- 変更前の全レコードをエクスポートして保管する
- TTLを事前に短くする（変更の1〜2日前に300秒程度へ）
- 変更内容を第三者にレビューしてもらう — タイプミス1文字で全断します
- 業務時間外・週末に実施する — 特にMXレコードの変更
- 変更後に外部から確認する — 社内ネットワークのキャッシュでは正しく検証できません
- TTLを元に戻す
3のレビューは省略されがちですが、最も効果があります。 DNSレコードは1文字の誤りで全社のメールが止まるため、1人で作業して1人で確認する体制は避けてください。
誰が管理しているかを明確にする
中小企業でよくあるのが、ドメインの管理権限がWeb制作会社やベンダーにあり、自社で変更できない状態です。
- ドメインの登録者（レジストラ）はどこか
- 管理画面のアカウントは誰が持っているか
- DNSレコードの変更を誰に依頼すればよいか
これらが不明な場合、M365の導入やサイトのリニューアルの際に作業が止まります。平常時に確認し、可能であれば自社で管理権限を持つようにしてください。ベンダーとの関係が終了した際にドメインを引き取れず、事業に影響が出る事例もあります。
まとめ
- DNSのトラブルは全社に影響し、かつ待ち時間が発生する。事前の理解と慎重な手順が重要
- MXレコードは優先度の数値が小さいほうが優先。移行後に旧サーバーのレコードが残ると一部メールが旧環境へ流れる
- DMARCは必ず p=none から。いきなり reject にすると正規のメールが拒否される
- SPFには10回のDNSクエリ上限がある。include を増やしすぎると認証が失敗する
- CAAレコードを設定すると、第三者による不正な証明書取得を防げる
- 「自分だけ見える」現象はキャッシュが原因。パブリックDNSを明示して確認する
- ネームサーバー変更は最も事故が多い操作。旧レコードを必ずエクスポートしてから切り替える
- ドメインの有効期限切れは実害が最大。自動更新・共有メールでの受信・カード期限に注意
- 変更手順はエクスポート → TTL短縮 → 第三者レビュー → 時間外実施 → 外部から確認
- 1文字のミスで全社のメールが止まる。1人作業・1人確認の体制は避ける
- ドメインの管理権限が自社にあるかを平常時に確認しておく
DNSは「見えないインフラ」ですが、その重要性は極めて高いです。特にメール認証（SPF/DKIM/DMARC）の設定は、メールの到達率とセキュリティに直結します。
情シス365では、DNS管理を含むドメイン・メール環境の運用をサポートしています。現状の設定を確認したい場合は無料相談からご相談ください。