DNSリソースレコード徹底解説

はじめに

WebサイトのURLを入力したら目的のページが表示される、メールアドレス宛にメールを送ったら相手に届く。
普段何気なく利用しているインターネットの仕組みですが、その裏側では DNS (Domain Name System) というシステムが重要な役割を担っています。

そして、そのDNSの中核をなすのが、今回解説する「リソースレコード」です。

この記事では、

• リソースレコードってどんな種類があるの？
• Aレコード、MXレコード、CNAMEレコード…よく聞くけど、それぞれ何が違うの？

といった疑問に答えていきます。
主要なリソースレコードの種類とその役割をわかりやすく解説していきます。

DNSの基本的な仕組み、例えば「ドメイン名とは何か？」「インターネット上で名前解決がどのように行われるのか？」といった点については、まず以下の記事で理解を深めておくことをおすすめします。

あわせて読みたい

バックエンドエンジニアのためのDNS基礎 はじめに Webアプリケーションを開発し、ユーザーに届けるバックエンドエンジニアにとって、ネットワークの知識は避けて通れません。中でも「DNS」は、私たちが普段何気...

この記事の対象読者

• スキルアップを目指す若手バックエンドエンジニア (経験1～3年目くらい)
• ネットワークやインフラの知識を基礎からしっかり学びたいと考えている方
• 業務でDNS設定に触れる機会がある、または今後増えそうな方

この記事のゴール

読み終える頃には、以下の状態になっていることを目指します。

• A, AAAA, MX, CNAME, TXTなど、主要なリソースレコードの種類と役割を自分の言葉で説明できる
• DNSの管理画面や設定ファイルを見たときに、「あ、これは〇〇を設定しているんだな」と大まかに内容を理解できる
• ゾーンファイルが読める

ドメイン名の表記方法

www.example.com のようなドメイン名、私たちにはすっかりお馴染みですよね。
でも実は、このドメイン名の書き方にはいくつかの種類があるんです。
リソースレコードを解読する際の前提知識となるので、ここでぜひ理解しておきましょう。

絶対ドメイン名

ドメイン名をTLDまで省略なく表記し、末尾にルートを表す.を付けたドメイン名です。
ルートからのすべてのラベルを含むドメイン名であることを間違いなく表記できるというメリットがあります。

例: www.example.com.

相対ドメイン名

ドメイン名を省略して表記したものです。
ベースとなるドメイン名が定まっている状態で、そのドメイン名からの相対位置で話をする場合に使われます。

例: example.comの話をしているときにおけるwww

完全修飾ドメイン名: FQDN = Fully Qualified Domain Name

TLDまでのすべてのラベルを含むドメイン名です。
絶対ドメイン名と異なり、末尾に.を付けるかどうかは、場面によって使い分けられます。
URLやメールアドレスの表記など、すべてのラベルを含む情報を必ず書くことが前提となる場合、末尾の.を付けないことが一般的です。

例: www.example.com

リソースレコードの種類と役割

本題に入りましょう。
と、その前に、リソースレコード自体のフォーマットなど基本的な事項は以下で解説していますので、よろしければそちらからご覧ください。

あわせて読みたい

バックエンドエンジニアのためのDNS基礎 はじめに Webアプリケーションを開発し、ユーザーに届けるバックエンドエンジニアにとって、ネットワークの知識は避けて通れません。中でも「DNS」は、私たちが普段何気...

SOAリソースレコード

ゾーンの管理に関する基本的な情報です。

example.com.    IN SOA    (
    ns1.example.com.    ; MNAME
    admin.example.com.  ; RNAME
    2025050601          ; SERIAL
    3600                ; REFRESH
    900                 ; RETRY
    604800              ; EXPIRE
    3600                ; MINIMUM
    )

• example.com.: このゾーンのドメイン名
• IN SOA: クラスとタイプ
• MNAME: そのゾーンのプライマリサーバーのホスト名
• RNAME: そのゾーンの管理者のメールアドレス、@を.に置き換えて設定
• SERIAL: ゾーンデータのシリアル番号が入る、値が大きければ大きいほど最新の情報、セカンダリサーバーはこの値を見てゾーン転送が必要かどうかを判断する
• REFRESH: ゾーンデータの更新を自発的に始めるまでの秒数、セカンダリサーバーはこの時間経過後にゾーンデータの更新がないかを確認する
• RETRY: ゾーンデータの更新が失敗した際に再度更新を試みるまでの秒数
• EXPIRE: ゾーンデータの更新の失敗が続くとき期限切れとみなすまでの秒数、古い情報を伝達する不正動作を防ぐ
• MINIMUM: ネガティブキャッシュを保持していい秒数

NSリソースレコード

委任に関する情報です。

自分自身のネームサーバーの情報と、委任先があれば委任先のネームサーバーの情報を記載します。

ここでは、example.comゾーンにおける記述例を示します。
また、sales.example.comという委任先が存在するとします。

example.com.              IN NS    ns1.example.com.
example.com.              IN NS    ns2.example.com.
ns1.example.com.          IN A     192.0.2.11
ns2.example.com.          IN A     198.51.100.21

sales.example.com.        IN NS    ns1.sales.example.com.
sales.example.com.        IN NS    ns2.sales.example.com.
ns1.sales.example.com.    IN A     192.0.2.31
ns2.sales.example.com.    IN A     198.51.100.41

A/AAAAリソースレコード

ドメイン名に対するIPアドレスです。

AレコードはIPv4、AAAAレコードはIPv6です。

www.example.com.    IN A       192.0.2.1
www.example.com.    IN AAAA    2001:db8::1

MXリソースレコード

メール配送に関する情報です。

example.com宛のメール、たとえばuser@example.com宛にメールが送信されたら、mx1.example.comやmx2.example.comというメールサーバーを配送先として設定する例を示します。

example.com.        IN MX      10 mx1.example.com.
example.com.        IN MX      20 mx2.example.com.
mx1.example.com.    IN A       192.0.2.2
mx2.example.com.    IN AAAA    2001:db8::2

10や20という数字は優先度を示しており、優先度の高い順にメールの配送を試みます。

CNAMEリソースレコード

ドメイン名に対する正式名です。

外部のサービスを自社のドメイン名で利用する際によく利用されます。
たとえば、外部が提供するCDNサービスを利用する例を見てみましょう。

src.example.com    IN CNAME    cdn.external.dev.

CNAMEレコードには以下の通り制限事項があります。

• CNAMEリソースレコードを設定したドメイン名にはCNAME以外のリソースレコードを設定してはならない
• 一つのドメイン名に複数のCNAMEリソースレコードを設定してはならない

TXTリソースレコード

任意の文字列です。

主になりすましメール対策などに利用されます。

example.com.           IN TXT    "v=spf1 +mx -all"
_dmarc.example.com.    IN TXT    "v=DMARC1;p=none;rua=dmarc-reports@example.com"

1行目はSPF、2行目はDMARCという、なりすましメール対策のための送信ドメイン認証で使う情報を設定しています。

PTRリソースレコード

IPアドレスに対するドメイン名です。

逆引きで使われます。
IPv4の場合、IPアドレスを逆順にした上で、特定のドメイン名であるin-addr.arpa.を付与したものを使います。
192.0.2.3に対応するドメイン名がptr1.example.com.の場合の設定例は以下です。

3.2.0.192.in-addr.arpa.    IN PTR    ptr1.example.com.

ゾーンファイル

権威サーバーが読み込むゾーンファイルは、ここまで説明したリソースレコードの内容をまとめたものになります。

example.com.               IN SOA      (
    ns1.example.com.    ; MNAME
    admin.example.com.  ; RNAME
    2025050601          ; SERIAL
    3600                ; REFRESH
    900                 ; RETRY
    604800              ; EXPIRE
    3600                ; MINIMUM
    )

example.com.               IN NS       ns1.example.com.
example.com.               IN NS       ns2.example.com.
ns1.example.com.           IN A        192.0.2.11
ns2.example.com.           IN A        198.51.100.21
sales.example.com.         IN NS       ns1.sales.example.com.
sales.example.com.         IN NS       ns2.sales.example.com.
ns1.sales.example.com.     IN A        192.0.2.31
ns2.sales.example.com.     IN A        198.51.100.41

www.example.com.           IN A        192.0.2.1
www.example.com.           IN AAAA     2001:db8::1

example.com.               IN MX       10 mx1.example.com.
example.com.               IN MX       20 mx2.example.com.
mx1.example.com.           IN A        192.0.2.2
mx2.example.com.           IN AAAA     2001:db8::2

src.example.com            IN CNAME    cdn.external.dev.
example.com.               IN TXT      "v=spf1 +mx -all"
_dmarc.example.com.        IN TXT      "v=DMARC1;p=none;rua=dmarc-reports@example.com"

3.2.0.192.in-addr.arpa.    IN PTR      ptr1.example.com.

書式にはRFCで定められており、具体的には以下ルールがあります。

• ;を使ってコメントが記載できる
• SOAリソースレコードのように1行が長くなる場合、カッコを使って複数行に分割できる
• 前行と同じドメイン名とクラスは省略できる
• $TTLディレクティブを使うことでデフォルトのTTLを指定できる
• $ORIGINディレクティブでそのゾーンのオリジン (相対ドメイン名を設定した際に補完されるドメイン名) を指定できる
• オリジンと同じドメイン名は@と記載できる
• ドメイン名のフィールドの末尾が.でない場合は相対ドメイン名となり、$ORIGINディレクティブで指定したドメイン名が末尾に補完される
• $INCLUDEディレクティブを用いると、設定されたファイルをゾーンファイルの中に読み込むことができる

これらのルールを適用した版が以下です。

$ORIGIN example.com.
$TTL 3600
@                          IN SOA   (
    ns1.example.com.    ; MNAME
    admin.example.com.  ; RNAME
    2025050601          ; SERIAL
    3600                ; REFRESH
    900                 ; RETRY
    604800              ; EXPIRE
    3600                ; MINIMUM
    )
                           NS       ns1.example.com.
                           NS       ns2.example.com.
                           MX       10 mx1.example.com.
                           MX       20 mx2.example.com.
                           TXT      "v=spf1 +mx -all"
_dmarc                     TXT      "v=DMARC1;p=none;rua=dmarc-reports@example.com"
sales                      NS       ns1.sales.example.com.
                           NS       ns2.sales.example.com.
www                        A        192.0.2.1
                           AAAA     2001:db8::1
mx1                        A        192.0.2.2
mx2                        AAAA     2001:db8::2
ns1                        A        192.0.2.11
ns2                        A        198.51.100.21
src                        CNAME    cdn.external.dev.
ns1.sales                  A        192.0.2.31
ns2.sales                  A        198.51.100.41
3.2.0.192.in-addr.arpa.    PTR      ptr1.example.com.

せっかくリソースレコードを理解しても、ゾーンファイルのフォーマットのせいで意味が読み取れないともったいないので、ぜひ知っておきましょう。

まとめ

今回は、バックエンドエンジニアなら知っておきたいDNSの基礎について幅広く解説してきました。

この記事で学んだ重要なポイントを振り返ってみましょう。

• ドメイン名の表記方法
  • 絶対ドメイン名: ドメイン名をTLDまで省略なく表記し、末尾にルートを表す.を付けたドメイン名
  • 相対ドメイン名: ドメイン名を省略して表記
  • 完全修飾ドメイン名 (FQDN): TLDまでのすべてのラベルを含むドメイン名
• リソースレコード
  • SOA: ゾーンの管理に関する基本的な情報
  • NS: 委任に関する情報
  • A/AAAA: ドメイン名に対するIPアドレス
  • MX: メール配送に関する情報
  • CNAME: ドメイン名に対する正式名
  • TXT: 任意の文字列
  • PTR: IPアドレスに対するドメイン名
• ゾーンファイルにはディレクティブや省略ルールなど独特な記法がある

DNSは普段あまり意識しないかもしれませんが、Webサービスが動作する上で不可欠な技術です。
今回学んだ知識は、インフラ担当者とのコミュニケーションや、システムトラブル時の原因究明など、バックエンドエンジニアとしての業務できっと役立つはずです。

ぜひ、この基礎知識を足がかりに、さらに理解を深めていってください。

参考文献

• DNSがよくわかる教科書