DNSレコードのキホン

はじめに

こんにちは！TechBull 運営チームの富田(@Cooking_ENG )です！この記事は、TechBull Advent Calendar 2025 の17日目の記事です。

バックエンドからSREキャリアチェンジして「DNSのレコード」の設定なども経験させていただきました。レコードも用途によって使い分けるため、さまざまな種類のレコードがあります。今回は備忘録として、業務で触ったレコードを中心にまとめていこうと思います。

DNSについて

まずは前提として DNS の役割を簡単に整理します。

DNS（Domain Name System）は、人間が覚えやすい「ドメイン名」と、機械が通信に使う「IP アドレス」を紐づける仕組みです。

例えばブラウザに example.com を入力しても、そのままではサーバには届きません。実際には DNS が「example.com = 192.0.2.1 のサーバだよ」という答えを返し、ブラウザはその IP に向かって通信します。

この紐付けを細かくコントロールするのが「DNS レコード」です。サービス構成や用途に合わせて種類を使い分ける必要があります。

DNSレコードの種類

ここからは SRE になってから実際に触る機会が多かったレコードを中心にまとめていこうと思います。

Aレコード

ドメイン名 → IPv4 アドレス を紐づける最も基本的なレコードです。

例:

キャンペーンサイトややイベントLPの公開などに使用されるケースが多いです。

CNAME レコード

別のドメイン名に“名前として”紐づけるレコード。別名（エイリアス）をつけるイメージです。

例:

注意点

ルートドメインexample.comは CNAME を使えない

以下のようなルートドメインに対して、CNAMEの設定はできないので注意してください。

これは、ルートドメイン（example.com）にはNS や SOA など、最初から必須のレコードが存在するため、CNAME を設定できない仕様になっているためです。

NS レコード

NS（Name Server）レコードは、あるドメイン（ゾーン）を「どの DNS サーバが管理しているか」を示すレコードです。

DNS における管理権限の委譲先を決める、非常に重要な役割を持っています。NS レコードは、「このドメイン配下の名前解決は、どの DNS サーバに問い合わせるか」を定義します。A レコードや CNAME レコードが通信先を決めるのに対し、NS レコードは名前解決を担当する DNS 自体を切り替えると考えるとイメージしやすいと思います。

例：

を親ゾーンとして管理しており、

を別の DNS で管理したい場合を考えます。

親ゾーンexample.comの NS レコード

この設定により、

以下の名前解決は 上記の DNS サーバに委譲されます。

子ゾーンdev.example.com側の設定例

子ゾーン側には、通常どおり A レコードや CNAME レコードを設定します。

これで、

という名前解決が成立します。

なぜ違う DNS で管理するのか

NS レコードを使ってサブドメインを 別の DNS で管理する理由は、影響範囲と権限を分けるためです。

• 本番と開発で管理を分けたい
• チームごとに DNS の変更権限を分けたい
• DNS 設定ミスで全体を止めたくない

このような場合に、dev.example.com などを別の DNS に委譲します。これにより、子ゾーン側の変更が親ゾーン全体に影響しにくくなり、安全に運用することができます。

※ ゾーンとは：ゾーンとは、DNS を管理する単位のことです。

例えば、

• example.com を管理するゾーン

• dev.example.com を管理するゾーン

は、別々のゾーンとして分けることができます。

TXT レコード

TXT レコードは、ドメインに対して任意のテキスト情報を持たせるためのレコードです。

「このドメインは本当に自分が管理しています」という証明やメールのなりすまし防止など、重要な役割で使われます。

例：ドメイン所有者の確認

外部サービスで「このドメインを本当に管理していますか？」と確認されることがあります。その場合、次のような TXT レコードを追加します。

これにより、指定された文字列を設定できる＝ドメイン管理者であると証明できます。

なお、TXTレコードは何の用途か分かるように コメントや管理表を残しておくと、他メンバーと共有するときなどに便利です。

よく使用されるTXTレコードの種類として

• SPF
  「このドメインからメールを送っていいサーバはどれか」を宣言する仕組み。

• DKIM
  メールに電子署名を付けて、「送信途中で改ざんされていないこと」を確認する仕組み。

• DMARC
  SPF や DKIM のチェック結果を使って、「失敗したメールをどう扱うか（拒否・隔離・許可）」を決めるポリシーの設定。

などがあります。（気になる方は調べてみてください。）

---

以下は業務では使用する機会がありませんでしたが、基本的なレコードなので、こちらも簡単にまとめておこうと思います。

MX レコード

MX（Mail Exchange）レコードは、そのドメイン宛てのメールを「どのメールサーバが受信するか」を指定するレコードです。

Web アクセスには使われず、メール配送専用のレコードになります。

MX 10 の10という数字は優先度を表しています。数字が小さいほど先に使われます。Google Workspace や Microsoft 365 を使う場合、指定された MX をそのまま設定するだけのケースがほとんどです。

SOA レコード

SOA（Start of Authority）レコードは、その DNS ゾーンの「基本情報と管理ルール」を持つレコードです。ゾーンごとに必ず 1 つ存在します。

SOA レコードに含まれる主な情報

• Serial：ゾーンのバージョン番号（変更管理用）
• Refresh / Retry：セカンダリ DNS がどの頻度で同期するか
• Expire：同期できなかった場合、どれくらい有効とみなすか
• Minimum TTL：キャッシュの最小時間

※ SOAレコードは多くの場合、DNSサービスが自動管理しています。編集することはほとんどありませんが、トラブルなどの調査時に見ることはあります。

DNS設定で気をつけていること

TTL を雑にしない

TTL は「DNS の情報がどれくらいキャッシュされるか」の時間です。

• 短すぎる： DNS への問い合わせが増え、負荷がかかる
• 長すぎる： 間違えた設定をすぐに戻せない

普段は 300〜600 秒 程度に設定してあることが多いですが、

設定変更は必ず二重三重で確認

DNS は 1 行のミスでサービスが止まる ことがあります。 IaC 化などで手作業を減らしレビューしてもらったり、ダブルチェックなどをしてもらうなど、1人で行わず、誰かに確認してもらうようにしましょう。

伝播遅延を考慮したスケジューリング

反映まで数分〜数時間かかるため、「変更したのに接続できない！」が起こるのはよくあります。運用フローに “DNS 伝播の待ち時間” なもを入れておくと焦らず対応できます。

終わりに

今回は業務で設定させていただいたDNSレコードを中心にまとめてみました。DNSの設定はサービスの立ち上げなどのタイミングしか触れないこともあるので、実際に設定してみて以前より理解が深まったと思います。

ネットワーク周りの知識は基礎として大切だと思っているので、引き続き学習していこうとおもいます。