DNS(Domain Name System)

よみ: ディーエヌエス

ドメイン名(www.example.com)を IP アドレスに変換する仕組みです。インターネットの「電話帳」にあたります。世界中の DNS サーバが階層的に役割分担しており、ブラウザは「.com を管理するサーバに聞く → example.com を管理するサーバに聞く」とたどって、最終的に Web サーバの IP に到達します。

DNS を触る際の心構え

押さえておきたいのは、「DNS は影響範囲が非常に大きく、慎重な操作が求められる」という点です。担当者が DNS を触る場面は意外と多く、以下のようなケースがあります。

ドメイン移管やサーバの変更
サブドメインの追加
Search Console のドメイン認証(TXT レコード追加)
メール配信ツールの導入(SPF / DKIM / DMARC 設定)

もし設定を 1 行間違えると、「全社の Web サイトが見られなくなり、メールも届かない」という大事故に直結します。

覚えておくべき主要レコード

A / AAAA：Web サイトの IP アドレスを指定。
CNAME：ドメインの別名(転送先)を指定。
MX レコード：メールの届け先を指定。
TXT：ツールの所有権証明や、メールのなりすまし防止(SPF 等)に使用。
NS：ドメインの管理をどのサーバに任せるかを指定。

実務での鉄則

変更時は、事前にTTL(キャッシュの有効期限)を 300 秒などに短くしておき、万が一の際もすぐ元に戻せるようにするのが定石です。また、変更後は「DNS Checker」などのツールで、世界中に設定が反映(伝播)されたかを確認しましょう。

よくある落とし穴(注意点)

SPF レコードの上書き：メール送信サービスの導入時に既存の SPF を上書きしてしまい、これまで使っていたメールが全部届かなくなる。
二重管理による不整合：レジストラ側の DNS とサーバ側の DNS にレコードを別々に書いてしまい、設定が食い違う。
NS レコードの切替：NS レコード自体を切り替えると、そこに紐づく全レコードがクリアされてしまう。
伝播待ちの失念：反映には時間がかかるため「直したのにまだ古いまま」と慌てる。変更前の現状をスクショで残し、変更内容を 1 行ずつ手順書にしてから触るのがチームの最低ルールです。

言葉をよく利用する人

インフラエンジニア
バックエンドエンジニア
情シス
Web 担当者(発注側)

会話上での使用例

サーバ移行の段取りを業者と擦り合わせる場面

インフラエンジニア
切替日の二日前にDNSの有効期限を300秒まで短くしておいて、当日にWeb向けのレコードを新サーバへ向けます。反映はおおむね30分から数時間です。
Web 担当者
了解です。メール向けのレコードは触らない前提ですよね。そこを変えてしまうとメールが止まるので、念のため確認させてください。
インフラエンジニア
はい、メール関連は一切変更しません。作業前に現状の設定を全部書き出して共有しておきます。

メール送信サービスの導入で認証用レコードを追加する場面

バックエンドエンジニア
送信サービスの認証で、SPFに一行追加をお願いしたいです。
Web 担当者
今のSPFはグーグルのものが入っているので、それを消さずに追記する形ですよね。既存を上書きしてしまうと今使っているメールが全部届かなくなるので、変更前と変更後のDNSの値を一度こちらに見せてもらえますか。