📘

Route 53のDNSレコードについて整理

に公開
AWS
レコード
idea

はじめに

自分の勉強も兼ねて、AWSのDNSサービスであるRoute 53で活用されるレコードの種類についてまとめます。

DNSのレコードとは

DNSレコードとは「ドメイン名と何かを紐づける設定」のことです。
Route 53やお名前.comなどでexample.comなどのドメインに紐づけて登録します。

よく使うレコードタイプ

タイプ 用途 名前（具体例） 値（具体例）
A Webサイト example.com 203.0.113.1
AAAA Webサイト example.com 2001:0db8::1
CNAME 別名 www.example.com example.com
MX メール example.com mail.example.com
TXT 認証など example.com "v=spf1 include:..."
NS ネームサーバー指定 example.com ns-123.awsdns-12.com

各レコード概要

  • A
    • ドメイン → IPv4アドレスで名前解決
  • AAAA
    • ドメイン → IPv6アドレスで名前解決
    • Aが4つなのはIPv6がIPv4の4倍のビット長（128bit）だから
  • CNAME
    • ドメイン → 別のドメインへ転送する。CNAME = Canonical Name（カノニカルネーム）で、「正規名」「本名」という意味
    • Zone Apex（example.com）には使用不可
    • AWSリソースにはエイリアスレコードを使う方がベター
  • MX
    • メールの送信先サーバーを指定
    • 優先度も設定する（例: 10 mail.example.com、数字が小さいほど優先）
  • TXT
    • テキスト情報を格納
    • SPF（メール送信元認証）、DKIM、ドメイン所有権確認などに使用
  • NS
    • このドメインを管理するネームサーバーを指定
    • Route 53でホストゾーン作成時に自動で設定される

それぞれなぜ必要なのか

ここを考えることで、各レコードの本質が理解できると思います。
AレコードやAAAAレコード(IPv6 ver)だけでいいのではと思いがちですがそれぞれでいい部分があります。

CNAME

  1. IPアドレスが変わる可能性があるサービスを使うとき
    例えば、CloudflontはIPがAWS側で自動付与されるサービスです。そこで、CNAMEでd1234.cloudfront.netと自分のドメインを繋げることで、
    サーバーのIP変更に自動で対応できます。
Aレコードで直接指定する場合、
www.example.com → 54.23.45.67（CloudFrontのIP）
                   ↑ IPが変わったら手動で更新必要

CNAMEで指定する場合
www.example.com → d1234.cloudfront.net → 54.23.45.67
                   ↑ AWS側がIP管理してくれる

※ ただし、DNSの仕様（RFC）で、「CNAMEは他のレコードと共存できない」+「Zone Apex(ルートドメイン) には NS と SOA レコードが必須で存在する」ということなので、Zone Apex に CNAME は設定不可です。サブドメインには設定可能です。
このため、エイリアスレコードができました。CloudFrontやALBなどAWS側でIPが動的に変わるサービスをルートドメインで使いたいケースに非常に有効です。さらに、CNAMEは「ドメイン→別ドメイン→IP」と2回の名前解決が必要ですが、エイリアスレコードはRoute 53が内部で解決して直接IPアドレスを返すため、高速です。また、同じAWSアカウント内のリソース（CloudFront、ALB、S3、API Gatewayなど）へのエイリアスクエリは無料です。

  1. 複数サブドメインを一元管理
    もしCNAMEがない場合、それぞれのサブドメインに対して個別にAレコードでIPと結びつける必要があります。
  app.example.com  → 203.0.113.1
  api.example.com  → 203.0.113.1
  www.example.com  → 203.0.113.1
  ↑ IP変わったら全部変更...

これがCNAMEがあることで、一旦ルートドメインとサブドメインを繋げることができます。
こうすることで、IPが変更する際、ルートドメインとIPの関係性だけを変更するだけで良くなります。

  app.example.com  → example.com
  api.example.com  → example.com
  www.example.com  → example.com
  example.com      → 203.0.113.1（ここだけ管理）

「IPアドレスを直接管理したくない」 ときにCNAMEを使うのがいいと思います。

MX

  1. メールの配送先を柔軟に指定できる
    メールサーバーはWebサーバーとは別のIPアドレスで運用することが多いです。MXレコードがあることで、ドメインの「Webサイト」と「メール」を別々のサーバーに振り分けられます。
example.com（Webサイト用）
  Aレコード → 203.0.113.1（Webサーバー）

example.com（メール用）
  MXレコード → mail.example.com → 198.51.100.1（メールサーバー）
  1. 冗長性（フェイルオーバー）の確保
    MXレコードには「優先度」を設定できます。これにより、メインのメールサーバーがダウンしても、バックアップサーバーで受信できます。
example.com  MX  10 mail1.example.com  ← 優先（数字が小さい）
example.com  MX  20 mail2.example.com  ← バックアップ
example.com  MX  30 mail3.example.com  ← 第3候補
  1. 外部メールサービスの利用
    Google WorkspaceやMicrosoft 365などの外部メールサービスを使う場合、MXレコードでそのサービスのメールサーバーを指定するだけで、自社ドメインでメールが使えるようになります。
example.com  MX  1 aspmx.l.google.com
example.com  MX  5 alt1.aspmx.l.google.com

TXT

  1. ドメインの所有権証明
    Google Search ConsoleやAWSなどのサービスで「このドメインは本当にあなたのものですか？」と確認されるとき、指定された文字列をTXTレコードに設定することで証明できます。
example.com  TXT  "google-site-verification=abc123..."
  1. メールのセキュリティ強化
    SPF、DKIM、DMARCといったメール認証の仕組みはすべてTXTレコードで設定します。これにより、なりすましメールを防止できます。
# SPF: **このドメインからメールを送れるサーバーを宣言**
example.com  TXT  "v=spf1 include:_spf.google.com ~all"

# DMARC: **認証に失敗したメールの扱いを指定**
_dmarc.example.com  TXT  "v=DMARC1; p=reject;"

NS

  1. ドメインの管理権限の委任
    「このドメインのDNS情報はどのネームサーバーに聞けばいいか」を世界に伝える役割があります。
# お名前.comで取得したドメインをRoute 53で管理する場合
example.com  NS  ns-123.awsdns-12.com
example.com  NS  ns-456.awsdns-34.net
             ↑ 「Route 53に聞いてね」と伝える
  1. サブドメインの管理委任
    大規模な組織では、サブドメインを別チームや別システムで管理したいケースがあります。NSレコードで委任できます。
# dev.example.com は開発チームの別アカウントで管理
dev.example.com  NS  ns-789.awsdns-56.org

終わりに

他の解説も順次進めていきます。

参考

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/ResourceRecordTypes.html

Discussion