MENU

DNS レコードの種類と役割｜A と CNAME の違いと使い分けの早見表

ネットワーク
  • URLをコピーしました！
目次

はじめに

私たちが普段、Web サイトを閲覧したりメールを送受信したりできるのは、裏側で DNS（Domain Name System）が名前解決を提供しているためです。

DNS の役割を簡潔に言うと、「インターネット上の電話帳（アドレス帳）」です。コンピュータ同士は「IP アドレス（例: 192.0.2.1）」という数字でお互いを認識していますが、人間がこれをすべて覚えるのは現実的ではありません。そこで、google.com や mytech-blog.com といった覚えやすいドメイン名を使い、DNS が裏側でこれを IP アドレスに変換（名前解決）しています。

まずはこちらの DNS Lookup Tool にアクセスし、google.com と入力して CHECK をクリックすると、動作を確認できます。

インストール不要・Web 版の DNS ルックアップツールです。A / MX / NS / TXT / SPF レコードを一括取得します。複数のレコード情報（IP アドレス、メールサーバー、ネームサーバーなど）が一覧で表示されます。これらが DNS レコードであり、本記事ではそれぞれの意味と役割について解説します。

この記事でわかること
  • DNS の基本的な仕組みと名前解決の流れ
  • 主要 DNS レコードの役割一覧（A / AAAA / CNAME / MX / NS / TXT / SOA / PTR / CAA / SRV / HTTPS）
  • A レコードと CNAME レコードの使い分け・実務での注意点
  • TXT レコードでのメール認証（SPF / DKIM / DMARC）の基本
  • ルートドメインで CNAME が使えない理由と、Alias / HTTPS レコードによる回避策
  • nslookup / dig / Resolve-DnsName での設定反映確認

DNS は「インターネットの電話帳」として、ドメイン名と IP アドレスをつなぐ名前解決を担います。値が IP アドレスなら A / AAAA レコード、ドメイン名なら CNAME レコードが基本となり、ルートドメインでは CNAME が使えないため Alias 機能や HTTPS レコードで代替します。本記事では、各レコードの役割と使い分けを早見表と確認コマンドを交えて整理します。

DNS とは？ドメインと IP アドレスをつなぐ基本

インターネットの世界では、「人間が使う表記」と「コンピュータが使う表記」が異なります。この 2 つを橋渡しするのが DNS の役割です。

人間は「ドメイン名」、コンピュータは「IP アドレス」

Web サイトを閲覧する際、人間は google.com や mytech-blog.com といったドメイン名（文字）を使います。一方、Web サーバーなどのコンピュータは 142.250.196.14 のような IP アドレス（数字）で通信相手を特定します。

DNS がなければ、Web サイトを紹介する際に IP アドレスをそのまま伝える必要があり、実用性が大きく下がります。

DNS サーバーは、人間が入力した「ドメイン名」を受け取り、対応する「IP アドレス」を返します。この変換処理を「名前解決（Name Resolution）」と呼びます。

ドメイン・ホスト名・FQDN の関係性

DNS 設定を行ううえで重要なのが、「ホスト名」「ドメイン名」「FQDN（完全修飾ドメイン名）」の違いです。www.google.com の場合、どこまでがドメインで、どれがホスト名でしょうか。

  • ホスト名: www（サーバー個体の名前）
  • ドメイン名: google.com（組織のグループ名）
  • FQDN: www.google.com（すべてを繋げた絶対的な住所）

この区別が曖昧なままだと、CNAME レコードの設定や SSL 証明書の取得時に混乱の原因になります。

それぞれの定義と違いについては、関連記事『FQDN とサブドメイン・ホスト名の違いとネイキッドドメインの落とし穴』で図解付きで解説しています。

主要 DNS レコード早見表

DNS レコードには多くの種類があります。まず全体像を把握してから各セクションの詳細を読むことで、理解が深まります。

レコード種類値の形式主な用途典型的な TTL
AIPv4 アドレスWeb サーバーの IP 指定3600（1 時間）
AAAAIPv6 アドレスIPv6 対応 Web サーバーの IP 指定3600（1 時間）
CNAMEドメイン名別名定義・CDN 接続3600（1 時間）
MX優先度 + ドメイン名メール配送先の指定3600（1 時間）
NSドメイン名権威ネームサーバーの指定86400（24 時間）
TXT任意のテキストSPF / DKIM / DMARC / ドメイン所有権証明3600（1 時間）
SOAゾーン管理情報ゾーンのメタデータ（自動管理）自動
PTRドメイン名逆引き DNS（IP からドメインへの変換）3600（1 時間）
CAAフラグ + タグ + 値SSL 証明書発行可能な CA の指定3600（1 時間）
SRV優先度 + 重み + ポート + ドメイン名サービスのホストとポートの指定（VoIP / XMPP など）300（5 分）
HTTPS接続パラメータ（RFC 9460）HTTPS 接続情報の事前提供・HTTP/3 対応300（5 分）

TTL（Time To Live）は、DNS キャッシュの有効期間を秒単位で指定します。変更頻度が低いレコードには長い TTL、CDN 切り替えや移行前には短い TTL（300 など）を設定するのが一般的です。

参考: Cloudflare DNS Documentation – DNS record types
“Each DNS record has a TTL which stands for ‘time to live’.”
（各 DNS レコードには TTL（time to live）があります）
https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/

A レコード / AAAA レコード

A レコード（Address Record）

最も基本的なレコードで、ドメイン名と IPv4 アドレスを直接紐づけます。「このドメインにアクセスが来たら、この IP アドレスのサーバーへ向ける」という指示を担うレコードです。

設定例

example.com.       3600  IN  A  100.64.1.1
www.example.com.   3600  IN  A  100.64.1.2

用途

  • Web サーバーの指定
  • VPN ゲートウェイの指定
  • 冗長化のための複数 IP 指定（ラウンドロビン DNS）

同じドメイン名に対して複数の A レコードを登録すると、DNS サーバーは問い合わせごとに異なる IP を応答します（ラウンドロビン DNS）簡易的な負荷分散として使われますが、各サーバーの稼働状態までは判定しないため、本格的な負荷分散にはロードバランサーの利用が推奨されます。

AAAA レコード（クワッドエー）

A レコードの IPv6 版です。ドメイン名と IPv6 アドレスを紐づけます。

設定例

example.com.  3600  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

IPv4 と IPv6 の両方に対応する環境（デュアルスタック）では、同じドメイン名に対して A レコードと AAAA レコードの両方を登録します。クライアント側の OS やブラウザが、利用可能なプロトコルに応じて自動で選択します。

CNAME レコード（Canonical Name Record）

あるドメイン名を、別のドメイン名に転送（エイリアス）するレコードです。IP アドレスではなくドメイン名で指定するのが特徴です。

よく「リダイレクト」と混同されますが、HTTP リダイレクト（URL 自体が変わる）とは異なり、CNAME は DNS レベルでの別名定義です。ブラウザのアドレスバーの URL は変わりません。

設定例

piyo.example.com.  3600  IN  CNAME  hoge.example.com.
www.example.com.   3600  IN  CNAME  example.com.

用途

  • www ありのドメインを www なしのドメインと同じ場所に向けたいとき
  • CDN やロードバランサーなど、IP アドレスが動的に変わるクラウドサービスを参照するとき

CNAME チェーンに注意

CNAME が別の CNAME を指すような多段構成（CNAME チェーン）は、DNS 解決のたびに再帰的に問い合わせが発生し、パフォーマンスが低下します。

a.example.com.  CNAME  b.example.com.
b.example.com.  CNAME  c.example.com.
c.example.com.  A      100.64.1.1

上記の例では、a.example.com の解決に 3 段階の問い合わせが必要です。CNAME は 1 段で終わらせる設計が推奨されます。

MX レコード（Mail Exchange Record）

そのドメイン宛（@example.com）のメールを、どのメールサーバーに配送するかを指定します。

MX レコードには「優先順位（Priority）」の設定値があり、複数のメールサーバーを登録して冗長化できます。数値が小さいほど優先度が高く、優先度の高いサーバーから順に配送が試みられます。

設定例

example.com.  3600  IN  MX  10  mail.google.com.
example.com.  3600  IN  MX  20  backup-mail.google.com.
  • 優先度 10: メイン配送先
  • 優先度 20: メインが応答しない場合のバックアップ

MX の値には CNAME を指定できない

MX レコードの値（配送先）には、IP アドレスではなく FQDN（ホスト名）を指定します。ただし、ここで指定する FQDN は A レコードまたは AAAA レコードで直接解決できる必要があり、CNAME を指定することは DNS 仕様上認められていません。

参考: RFC 2181 – Clarifications to the DNS Specification（Section 10.3）
“The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.”
（NS レコードの値、または MX レコードの値の一部として使われるドメイン名は、エイリアス（CNAME）であってはなりません）
https://www.rfc-editor.org/rfc/rfc2181

# 誤り: CNAME を MX の値に指定
example.com.      MX     10  mail.example.com.
mail.example.com. CNAME  mailserver.gmail.com.

# 正しい: A レコードで解決できるホスト名を指定
example.com.      MX  10  mail.example.com.
mail.example.com. A   100.64.10.1

メールシステムで Host not found 等のエラーが出る場合、この制約違反が原因となっているケースがあります。

NS レコード（Name Server Record）

そのドメインの DNS 情報を管理しているサーバー（権威サーバー）を指定するレコードです。「このドメインの情報は、このネームサーバーに問い合わせる」という宣言を担います。

通常、ドメインを取得した事業者（お名前.com や GoDaddy など）の管理画面で設定し、実際にレコードを編集する DNS サーバー（AWS Route 53 や Cloudflare など）を指定します。

設定例

example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

NS レコードの実務ポイント

最低 2 つの NS レコードが必要
冗長性のため、1 つのネームサーバーが停止しても名前解決が継続できるよう、2 つ以上の登録が一般的です。主要 DNS プロバイダー（Cloudflare / Route 53 など）は最初から複数のネームサーバーを自動で割り当てます。

地理的・ネットワーク的に分散された配置が推奨
同一データセンター内の複数台より、異なる AS・異なる地域のサーバーを指定することで可用性が向上します。

TTL は長めの値（86400 = 24 時間など）が一般的
NS レコードの変更は頻繁ではなく、かつ全世界に伝播するのに時間がかかるため、長い TTL が設定されます。

NS レコードが正しく設定されていないと、A レコードや MX レコードをいくら設定しても、インターネットからは情報を参照できません。

TXT レコード（Text Record）

任意のテキストを DNS に格納できるレコードです。元来は管理者向けのメモとして設計されましたが、現在はメール認証（SPF / DKIM / DMARC）やドメイン所有権の証明など、セキュリティ上欠かせない用途に広く使われています。

設定例（基本形式）

example.com.  3600  IN  TXT  "任意のテキスト文字列"

TXT レコードは同一ドメインに複数登録可能ですが、SPF レコードだけは 1 ドメインにつき 1 つのみという制約があります（複数設定すると認証エラーになります）。

SPF レコード（Sender Policy Framework）

「どの IP アドレスからの送信を正規と認めるか」をドメインオーナーが宣言するレコードです。受信側のメールサーバーが SPF レコードを参照し、送信元 IP がリストに含まれているかを確認します。

設定例

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:100.64.0.1 ~all"
要素意味
v=spf1SPF バージョン（固定値）
include:_spf.google.comGoogle の送信サーバーを許可（Google Workspace など）
ip4:100.64.0.1特定の IP アドレスを直接許可
~allリスト外の IP はソフトフェイル（受信するが迷惑メールフォルダ等に振り分ける可能性あり）
-allリスト外の IP はハードフェイル（拒否。強制力が高い）

注意: 1 ドメインに SPF TXT レコードを 2 つ以上設定すると、RFC 7208 §3.2 の規定により認証に失敗します。複数のメール送信サービスを使う場合は、1 つの SPF レコードに include でまとめる設計が必要です。

SPF レコードの評価には、DNS ルックアップ回数の上限もあります。 include・a・mx・ptr・exists と redirect のように DNS 問い合わせを伴うメカニズムは合計 10 個までと RFC 7208 §4.6.4 で定められており、これを超えると受信側は PermError（恒久エラー）を返します（ip4・ip6・all はカウント対象外）。複数のクラウドメールサービスを併用すると、include の入れ子で上限に達しやすくなります。PermError は SPF 認証の失敗として扱われ、SPF のみでアライメントを取っている場合は DMARC も連鎖的に失敗します。加えて、応答が空（NXDOMAIN）となる void ルックアップは 2 回までという制限もあります。

参考: RFC 7208 – Sender Policy Framework (SPF)（Section 4.6.4）
“SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation.”
（SPF 実装は、評価時に DNS ルックアップを伴う項の合計を 10 個までに制限しなければなりません）
https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

DKIM レコード（DomainKeys Identified Mail）

送信したメールに電子署名を付与し、改ざんが行われていないことを受信側が検証できる仕組みです。秘密鍵はメールサーバー側で保持し、対応する公開鍵を TXT レコードとして DNS に公開します。

設定例

selector1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."
要素意味
selector1._domainkeyセレクター名 + _domainkey（サブドメインとして設定）
v=DKIM1DKIM バージョン（固定値）
k=rsa鍵アルゴリズム
p=MIGf…公開鍵（実際にはより長い文字列）

DKIM の公開鍵は、Google Workspace や Microsoft 365 などのメールサービスが自動生成します。管理画面から生成された TXT レコード値をそのままコピーして DNS に登録するのが一般的な手順です。

DMARC レコード（Domain-based Message Authentication, Reporting and Conformance）

SPF と DKIM の結果を踏まえて、認証に失敗したメールをどう処理するかのポリシーを受信側に伝えるレコードです。レポートを受け取ることで、自ドメインからの不正送信（なりすまし）の検知にも役立ちます。

設定例

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"
要素意味
v=DMARC1DMARC バージョン（固定値）
p=none監視のみ（ポリシーを適用しない。まず none から始めて状況を把握することが推奨）
p=quarantine認証失敗メールを迷惑メールフォルダ等に振り分け
p=reject認証失敗メールを拒否
rua=mailto:…集計レポートの送付先アドレス
pct=100ポリシーを適用するメールの割合（100 = すべて）

参考: Google Workspace Help – Set up DMARC
“Here’s an example DMARC record: v=DMARC1; p=reject; rua=mailto:…”
（DMARC レコードの例: v=DMARC1; p=reject; rua=mailto:…）
https://support.google.com/a/answer/2466580

SPF・DKIM・DMARC の関係性

  • SPF: 「このサーバーからの送信は正規です（IP ベース）」
  • DKIM: 「このメールは正規のサーバーが署名しました（鍵ベース）」
  • DMARC: 「SPF / DKIM の検証結果に応じてどう処理するか」のポリシーと報告

2024 年 2 月以降、Gmail および Yahoo の一括送信者ガイドラインにより、1 日 5,000 通以上送信するドメインに対して SPF / DKIM / DMARC の設定が事実上必須化されました。さらに 2025 年 5 月 5 日からは、Microsoft も outlook.com・hotmail.com・live.com 宛ての大口送信者（1 日 5,000 通以上）に同様の要件を適用し、要件を満たさないメールを拒否するようになっています。Gmail は当初 421（一時的なエラー）で段階的に運用していましたが、2025 年 11 月以降は要件未達のメールに 550（恒久的な拒否）を返す方向へ強化されています。一括送信者でない場合も、送達率の維持や迷惑メール判定の回避のため、3 つセットで設定することが推奨されます。

参照: Google メール送信者ガイドライン https://support.google.com/a/answer/81126
Microsoft「Outlook の高ボリューム送信者向け要件」 https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlooks-new-requirements-for-high-volume-senders/4399730

ドメイン所有権の証明

Google Search Console、AWS Certificate Manager、GitHub、各種 SaaS ツールなどは、TXT レコードでドメインの所有権を確認する方式を採用しています。

設定例

example.com.  3600  IN  TXT  "google-site-verification=abc123xyz..."
example.com.  3600  IN  TXT  "MS=ms12345678"

これらの TXT レコードは、確認完了後も削除せずに残しておくことが推奨されます（再確認が必要になるケースがあるため）。

その他のレコード

Web サイト・メールの基本運用では A / CNAME / MX / NS / TXT の 5 種類を主に扱いますが、以下のレコードも知識として押さえておくと、DNS トラブルの切り分けや、より高度な設定に役立ちます。

SOA レコード（Start of Authority）

ゾーンのメタデータを定義するレコードです。各 DNS ゾーンに 1 つだけ存在し、プライマリネームサーバー、管理者アドレス、ゾーンのシリアル番号、セカンダリサーバーの更新タイマーなどが格納されています。

通常は DNS プロバイダーが自動管理するため、ユーザーが直接編集することはほぼありません。

フォーマット

example.com.  3600  IN  SOA  ns1.example.com.  admin.example.com.  (
    2026042401  ; シリアル番号（ゾーン変更のたびに更新）
    7200        ; リフレッシュ（2 時間）
    3600        ; リトライ（1 時間）
    1209600     ; 有効期限（14 日）
    86400       ; ネガティブキャッシュ TTL（1 日）
)

PTR レコード（Pointer Record）

A レコードの逆方向、「IP アドレス → ドメイン名」への変換（逆引き DNS）を担うレコードです。

主な用途

  • メールサーバーの正当性確認: 多くのメール受信サーバーは、送信元 IP の PTR レコードを確認します。PTR が設定されていない、または設定が不整合だと、メールが迷惑メール扱いになるか拒否されることがあります。
  • セキュリティログやネットワーク監視での IP からのホスト名特定。

設定例（逆引きゾーン）

34.216.184.93.in-addr.arpa.  3600  IN  PTR  mail.example.com.

PTR レコードは、IP アドレスを割り当てている事業者（ISP / クラウドプロバイダー）側の DNS ゾーンに登録する必要があります。自社 DNS での設定だけでは機能しない点に注意が必要です。

CAA レコード（Certification Authority Authorization）

どの認証局（CA）が自ドメインの SSL/TLS 証明書を発行できるかを制限するレコードです（RFC 8659。2019 年に RFC 6844 を更新）。

証明書の不正発行を防ぐセキュリティ用途で、認証局は証明書を発行する前に CAA レコードを確認することが、CA/Browser Forum の要件として定められています。

設定例

example.com.  3600  IN  CAA  0  issue     "letsencrypt.org"
example.com.  3600  IN  CAA  0  issuewild "letsencrypt.org"
example.com.  3600  IN  CAA  0  iodef     "mailto:security@example.com"
タグ意味
issue通常証明書の発行を許可する CA を指定
issuewildワイルドカード証明書の発行を許可する CA を指定
iodefポリシー違反があった場合の通知先

CAA レコードはサブドメインに継承されます。example.com に設定した CAA は sub.example.com にも適用されます（サブドメイン側で上書き可能）

参考: RFC 8659 – DNS Certification Authority Authorization (CAA) Resource Record
“This document obsoletes RFC 6844.”
（本文書は RFC 6844 を廃止し、置き換えます）
https://www.rfc-editor.org/info/rfc8659/

SRV レコード（Service Record）

特定のサービスが動作しているホスト名とポート番号を DNS で公開するレコードです。SIP（VoIP）、XMPP（チャット）、LDAP、Microsoft 365 の一部設定などで利用されます。

フォーマット

_service._protocol.example.com.  TTL  IN  SRV  優先度  重み  ポート  ターゲット

設定例（SIP VoIP）

_sip._tcp.example.com.  3600  IN  SRV  10  60  5060  sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  20  40  5060  sip2.example.com.
  • 優先度: 低い値が優先（MX と同じ考え方）
  • 重み: 同じ優先度の中でのトラフィック振り分け比率
  • ポート: サービスが稼働しているポート番号

HTTPS レコード（RFC 9460）

2023 年 11 月に IETF で標準化（RFC 9460）された新しいレコードタイプです。関連仕様として、RFC 9461 が暗号化 DNS（DoH）のサーバーマッピングを、RFC 9462 が DDR（Discovery of Designated Resolvers）を定義しています。クライアントが HTTP 接続の詳細（利用可能なプロトコル、ポート、サービスパラメータ）を DNS 段階で取得できるようになります。

参考: RFC 9460 – Service Binding and Parameter Specification via the DNS
“They also enable aliasing of apex domains, which is not possible with CNAME.”
（SVCB / HTTPS レコードは、CNAME では不可能な Apex ドメインのエイリアス化を実現します）
https://datatracker.ietf.org/doc/html/rfc9460

設定例

example.com.  300  IN  HTTPS  1  .  alpn="h2,h3" ipv4hint=93.184.216.34

HTTPS レコードの主な効果

HTTP → HTTPS リダイレクトの削減
クライアントが最初から HTTPS で接続できるため、リダイレクトに伴うラウンドトリップが不要になります。

HTTP/3（QUIC）の事前通知
alpn=”h3″ を指定することで、HTTP/3 に対応したクライアントが最初から HTTP/3 で接続できます。

Apex ドメインのエイリアス化
CNAME が使えない Zone Apex でも、HTTPS レコードを使うことで RFC 準拠のエイリアス化が実現できます。

Cloudflare、AWS Route 53 など主要 DNS サービスが HTTPS レコードに対応しており、2026 年時点では主要ブラウザ（Chrome / Firefox / Safari）も HTTPS レコードをサポートしています。各ブラウザの対応は、Firefox が 2020 年 5 月、Apple の Safari（iOS / macOS）が 2020 年 9 月、Chrome が 2020 年 12 月の部分対応から段階的に進み、現在は広く利用されています。

実践: A レコードと CNAME レコードの使い分け

DNS 設定で判断に迷いやすいのが「A レコードと CNAME レコード、どちらを使うべきか」という点です。基本的な使い分けの基準はシンプルです。

  • 指定したい値が「IP アドレス（数字）」の場合 → A レコード（例: 自社の Web サーバー（固定 IP）に向ける場合）
  • 指定したい値が「ドメイン名（文字）」の場合 → CNAME レコード（例: CDN、ロードバランサー、他社サービスに向ける場合）

次のフローで、値の種類とドメインの種類から使うべきレコードを判断できます。

図: 指定する値とドメインの種類による A / CNAME の使い分け。ルートドメインでは CNAME が使えず、Alias 機能か HTTPS レコードで代替する。

なお、CNAME はルートドメインで使えないだけでなく、MX レコードや NS レコードの値（参照先）にも指定できません（RFC 2181）。詳細は本記事「MX レコード」セクションを参照してください。

基本はこのルールで判断できますが、実務ではルートドメインに関する注意点を押さえておく必要があります。次のセクションで解説します。

ルートドメインの CNAME 問題と Alias レコードでの解決

A レコードと CNAME の使い分けで特に重要な注意点が、「ルートドメインには CNAME レコードを設定できない」という制約です。

「ルートドメイン（Apex ドメイン、ネイキッドドメイン）」とは、www などのサブドメインが付かない、ドメインそのもの（例: example.com）のことです。

DNS の仕様（RFC 1912 / RFC 1034）上、ルートドメインには CNAME レコードを設定できません。CNAME が設定されたノードには、他のレコード（MX や NS 等）を共存させることができないためです。

詳しい技術的背景（RFC の記述、トラブル事例、Alias / CNAME Flattening による回避策）については、関連記事『FQDN とサブドメイン・ホスト名の違いとネイキッドドメインの落とし穴』で解説しています。

クラウドサービス利用時の現実的な課題

AWS の ALB（Application Load Balancer）や Azure Front Door のように、接続先が IP アドレスではなくドメイン名で提供されるサービスをルートドメイン（example.com）で使いたい場合、次の状況になります。

  • A レコードは使えない（IP アドレスがわからない、または動的に変わる）
  • CNAME も使えない（ルートドメインでは RFC 仕様上設定不可）

このように、通常のレコード体系では行き詰まります。

解決策: 各クラウドの Alias 機能と HTTPS レコード

この課題を解決するため、主要なクラウド DNS サービスは独自機能を提供しています。

サービス機能名備考
AWS Route 53Alias レコードCloudFront / ELB / S3 等を指定可能
CloudflareCNAME FlatteningApex の CNAME を A/AAAA に自動変換
Azure DNSANAME 相当Azure Front Door / Traffic Manager 等と連携

これらは、「設定画面上では CNAME のようにドメイン名で指定できるが、実際の DNS 応答としては A レコード（IP アドレス）を返す」という挙動で、DNS の仕様を守りつつルートドメインをクラウドサービスに向けることを可能にします。

さらに、2023 年に標準化された RFC 9460（HTTPS / SVCB レコード）は、RFC 準拠の方法で Apex ドメインのエイリアス化を実現する新しい選択肢として注目されています。詳細は「その他のレコード」セクションの HTTPS レコードを参照してください。

クラウド環境でルートドメインを使う際は、これらの独自機能や HTTPS レコードの利用を検討することが推奨されます。

設定確認: nslookup / dig / Resolve-DnsName の使い方

DNS レコードを設定したら、反映を確認することが推奨されます。OS ごとに使えるコマンドが異なるため、環境に合わせて選択します。

  • Windows（コマンドプロンプト）: nslookup
  • Windows（PowerShell）: Resolve-DnsName（Microsoft 公式で推奨される新しいコマンド）
  • Linux / macOS: dig（より詳細な出力が得られる、エンジニアの間で主流）

nslookup（Windows）

オプションなしでドメイン名を入力すると、デフォルトで A レコードを問い合わせます。

C:\> nslookup example.com

実行結果の例

権限のない回答:
名前:    example.com
Address: 93.184.216.34

「権限のない回答」はエラー表示ではなく、「PC の既定の DNS サーバー（キャッシュサーバー）が代理で応答した」という意味です。IP アドレスが表示されていれば成功です。

特定のレコードタイプを指定するには -type= を使用します。

C:\> nslookup -type=mx example.com
C:\> nslookup -type=ns example.com
C:\> nslookup -type=cname www.example.com
C:\> nslookup -type=txt example.com
C:\> nslookup -type=caa example.com

dig（Linux / macOS）

dig は詳細な応答情報（TTL、権威情報、クエリ時間など）が得られます。任意のレコードタイプを名前で指定して問い合わせできます。

# A レコードの確認
dig example.com

# 特定のレコードタイプ
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com CAA
dig example.com HTTPS

# 指定した DNS サーバーへ問い合わせ（キャッシュ回避）
dig @8.8.8.8 example.com

# 短い出力形式で IP アドレスだけ取得
dig +short example.com

Resolve-DnsName（Windows PowerShell）

Windows 環境では、nslookup より柔軟な Resolve-DnsName の使用が推奨されています。

# A レコードの確認
Resolve-DnsName example.com

# 特定のレコードタイプ
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type NS
Resolve-DnsName example.com -Type TXT
Resolve-DnsName example.com -Type CAA

# 指定した DNS サーバーへ問い合わせ
Resolve-DnsName example.com -Server 8.8.8.8

HTTPS レコード（タイプ 65）は環境によって Resolve-DnsName が UNKNOWN と表示する場合があり、確認には dig の利用が確実です。

反映されないときは

DNS 設定の変更が世界中に伝播するまでには、TTL（Time To Live）で指定された時間分のタイムラグが発生します（数分〜数日）。「設定したのに反映されない」場合は、PC の DNS キャッシュが古い情報を保持している可能性があります。

Google の Public DNS（8.8.8.8）や Cloudflare（1.1.1.1）に直接問い合わせると、キャッシュの影響を受けずに現状を確認できます。

dig @8.8.8.8 example.com

新しい情報が返ってくれば、設定は正しく反映されており、あとは手元の環境への伝播を待つ段階です。

便利テクニック: DNS Lookup Tool の活用

本記事冒頭で紹介した DNS Lookup Tool は、内部で Google Public DNS（8.8.8.8）を参照しています。コマンドで 8.8.8.8 を指定しなくても、ツールで検索するだけで「世界中に設定が反映されているか」を確認できます。キャッシュの影響を避けたい場面で活用できます。

まとめ

本記事では、DNS の仕組みと代表的な DNS レコードの種類・役割について解説しました。値が IP アドレスなら A / AAAA、ドメイン名なら CNAME が基本ですが、ルートドメインや MX の値では CNAME が使えないという制約が判断の分かれ目になります。メール認証まわりは要件の厳格化が進んでおり、最新の運用状況を踏まえた設定が求められます。

  • DNS はドメイン名と IP アドレスをつなぐ名前解決を担う
  • A / AAAA レコードはドメイン名と IPv4 / IPv6 アドレスを紐づける
  • CNAME レコードはドメインに別名を付けるが、ルートドメインと MX の値には使えない
  • MX レコードはメール配送先を優先度付きで指定する
  • NS レコードはドメインの権威サーバーを指定し、最低 2 つが推奨
  • SPF / DKIM / DMARC は Gmail・Yahoo に加え Microsoft も大口送信者へ要件化
  • ルートドメインは Alias / CNAME Flattening や HTTPS レコード（RFC 9460）で対応

以上、最後までお読みいただきありがとうございました。

ネットワーク
DNS
よかったらシェアしてね！
  • URLをコピーしました！

この記事を書いた人

とものアバター とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

目次