DNS レコードタイプ

このページでは、Cloudflare で管理できる主な DNS レコードタイプを説明します。DNS レコードの追加、編集、削除の手順は、DNS レコードの管理 を参照してください。

Cloudflare 上の各ドメインには、少なくとも 1 件の IP アドレス解決 レコードが必要です。Cloudflare 経由で プロキシ できるのは、これらのレコードだけです。

A レコードと AAAA レコード ↗ は、ドメイン名を 1 つまたは複数の IPv4 または IPv6 アドレスに対応付けます。

これらのレコードには、次のフィールドがあります。

• 名前: サブドメイン、またはゾーン apex（@）。
  • 名前は、各ラベルが 63 文字以下（label1.label2.label3）で構成され、完全修飾ドメイン名（label1.label2.label3.example.com）が 253 文字を超えないようにします。
  • DNS ラベルには任意のオクテット（バイト値）を含められます。ただし、ホスト名および TLS 証明書との互換性のため、文字、数字、ハイフンのみを使うこと（LDH 規則）をおすすめします。これは DNS プロトコル上の要件ではないため、この規則に従わなくても DNS は動作します。
  • 先頭を文字にする必要はなく、末尾を文字または数字にする必要もありません。
  • アンダースコアは DNS で有効であり、サービスレコードでよく使われます。

• IPv4/IPv6 アドレス: オリジンサーバーのアドレス（Cloudflare IP ↗ は指定できません）

• TTL: Time to Live。DNS リゾルバーが再検証するまで応答をキャッシュする時間です。
  • プロキシステータス が プロキシ済み の場合、この値は Auto（300 秒）になります。
  • プロキシステータス が DNS のみ の場合、値をカスタマイズできます。
• プロキシステータス: 詳細は プロキシされた DNS レコード を参照してください。
• プライベートネットワークルーティング: 一部の Enterprise のお客様は プライベートネットワークルーティング も利用できます。A および AAAA レコードでは、公開ホスト名からプライベートネットワーク内のオリジンへ、HTTP/HTTPS トラフィックをプロキシできます。

API を使って A または AAAA レコードを作成するとき:

• レコードの content は IP アドレスです（A は IPv4、AAAA は IPv6）。
• proxied フィールドは、レコードの プロキシステータス に影響します。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"type": "A",
		"name": "www.example.com",
		"content": "192.0.2.1",
		"ttl": 3600,
		"proxied": false
	}'

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "www.example.com",
		"type": "A",
		"content": "192.0.2.1",
		"proxiable": true,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"meta": {
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2023-01-17T20:37:05.368097Z",
		"modified_on": "2023-01-17T20:37:05.368097Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

CNAME レコード ↗ は、ドメイン名を別の（正規の）ドメイン名に対応付けます。ターゲットのドメイン名にあるほかのレコードタイプを解決するときにも使えます。

これらのレコードには、次のフィールドがあります。

• 名前: サブドメイン、またはゾーン apex（@）。
  • 名前は、各ラベルが 63 文字以下（label1.label2.label3）で構成され、完全修飾ドメイン名（label1.label2.label3.example.com）が 253 文字を超えないようにします。
  • DNS ラベルには任意のオクテット（バイト値）を含められます。ただし、ホスト名および TLS 証明書との互換性のため、文字、数字、ハイフンのみを使うこと（LDH 規則）をおすすめします。これは DNS プロトコル上の要件ではないため、この規則に従わなくても DNS は動作します。
  • 先頭を文字にする必要はなく、末尾を文字または数字にする必要もありません。
  • アンダースコアは DNS で有効であり、サービスレコードでよく使われます。

• ターゲット: トラフィックの転送先ホスト名（example.com）。
• TTL: Time to Live。DNS リゾルバーが再検証するまで応答をキャッシュする時間です。
  • プロキシステータス が プロキシ済み の場合、この値は Auto（300 秒）になります。
  • プロキシステータス が DNS のみ の場合、値をカスタマイズできます。
• プロキシステータス: 詳細は プロキシされた DNS レコード を参照してください。

CNAME レコードを プロキシ済み から DNS のみへ、またはその逆へ変更する前に、特に次の点を確認してください。

• ホスト名でトラフィックをプロキシする場合、CNAME レコードで別の CNAME レコードを指すことができます（www.example2.com --> www.example1.com --> www.example.com）。ただし、最終レコードは有効な IP アドレスを持つホスト名（したがって有効な A または AAAA レコード）を指す必要があります。また、同じ名前に対するほかのレコードタイプのクエリはサポートされません。

• Cloudflare は、より良いパフォーマンスを出すために CNAME flattening という処理を使います。この処理はいくつかの機能を支え、CNAME レコードに依存するさまざまな構成 と相互作用する場合があります。詳細は CNAME flattening のセクション を参照してください。

• プロキシできない CNAME レコード（多くの場合、別の CDN プロバイダーに関連します）に遭遇した場合、そのレコードをプロキシすると接続エラーになります。Cloudflare は設定ミスから保護するため、意図的にそのレコードのプロキシを防いでいます。詳細は プロキシの制限 を参照してください。

API を使って CNAME レコードを作成するとき:

• レコードの content は 完全修飾ドメイン名 ↗ です。
• proxied フィールドは、レコードの プロキシステータス に影響します。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"type": "CNAME",
		"name": "www.example.com",
		"content": "www.another-example.com",
		"ttl": 3600,
		"proxied": false
	}'

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "www.example.com",
		"type": "CNAME",
		"content": "www.another-example.com",
		"proxiable": true,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"meta": {
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2023-01-17T20:37:05.368097Z",
		"modified_on": "2023-01-17T20:37:05.368097Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

これらのレコードは、ドメインからメールを送るかどうかにかかわらず推奨されます。安全なメールレコード ↗ を作成すると、ドメインをメールのなりすましから守りやすくなります。

ドメインをメール送信に使っていない場合は、推奨される 制限的なレコード ↗ の作成について確認してください。

メール交換（MX）レコードは、メールサーバーへメールを配送するために必要です。

• MX レコードの構文 ↗
• MX レコードを作成する

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

DomainKeys Identified Mail（DKIM）レコードは、メールに暗号署名を付けて真正性を保証します。

• DKIM レコードの構文 ↗
• DKIM レコードを作成する

Sender Policy Framework（SPF）レコードは、ドメインの代理でメールを送れる認可済み IP アドレスとドメインを列挙します。

• SPF レコードの構文 ↗
• SPF レコードを作成する

Domain-based Message Authentication Reporting and Conformance（DMARC）レコードは、メールトラフィックに関する集計レポートを生成し、非準拠メールの扱いについて受信側へ明確な指示を出します。

• DMARC レコードの構文 ↗
• DMARC レコードを作成する

テキスト（TXT）レコード ↗ は、DNS システムへテキストを登録できます。

TXT レコードのコンテンツは、二重引用符（"）で区切られた 1 つ以上のテキスト文字列です。引用符の使い方が揃っていないと（"this や "these" ones" など）、検証エラーになる場合があります。新しいレコードでは、引用符なしで TXT コンテンツを保存すると、Cloudflare が自動で二重引用符を付けます。詳細は What is a DNS TXT record ↗ を参照してください。

Cloudflare では、TXT レコードは主に、自分のドメイン または Cloudflare for SaaS ドメイン の SSL/TLS 証明書を発行する前に、ドメイン所有権を示すために使います。

TXT でメール認証レコードを作成することもできますが、代わりに Email security Wizard を使うことを推奨します。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

Certificate Authority Authorization（CAA）レコード は、ドメインの証明書を発行できる認証局（CA）を指定します。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

サービスレコード（SRV） ↗ は、Voice over IP（VOIP）やインスタントメッセージなど、特定サービスのホストとポートを指定します。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"type": "SRV",
		"name": "_xmpp._tcp.example.com",
		"data": {
				"priority": 10,
				"weight": 5,
				"port": 5223,
				"target": "server.example.com"
		}
	}'

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "_xmpp._tcp.example.com",
		"type": "SRV",
		"content": "5 5223 server.example.com",
		"priority": 10,
		"proxiable": false,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"data": {
			"port": 5223,
			"priority": 10,
			"target": "server.example.com",
			"weight": 5
		},
		"meta": {
			"auto_added": false,
			"managed_by_apps": false,
			"managed_by_argo_tunnel": false,
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2022-11-08T15:57:39.585977Z",
		"modified_on": "2022-11-08T15:57:39.585977Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

Service Binding（SVCB）レコードと HTTPS Service（HTTPS）レコードは、最初の平文 HTTP 接続なしに、サーバーへの接続方法をクライアントへ事前に伝えられます。

ドメインで HTTP/2 または HTTP/3 が有効 で、プロキシされた DNS レコード があり、Universal SSL も使っている場合、Cloudflare はクライアントへ接続方法を知らせるため、HTTPS レコードをその場で自動生成します。

プロキシ済み（オレンジクラウド） の名前では、Universal SSL が有効なとき、Cloudflare が HTTPS レコードを自動合成します。プロキシ済みの名前に手動で追加した HTTPS レコードは返されません。Cloudflare は自動生成したレコードを使います。

Universal SSL を無効にしている場合（たとえば Advanced Certificates だけを使っている場合）、Cloudflare はプロキシ済みの名前向けに HTTPS レコードを生成しません。

DNS のみ（グレークラウド） の名前では、HTTPS レコードを手動で追加でき、Cloudflare はそれを返します。ただし、手動の HTTPS レコードが返されるには、同じ名前のレコードがすべて DNS のみ である必要があります。

詳細と背景は、発表ブログ記事 ↗ と RFC 9460 ↗ を参照してください。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

ポインター（PTR）レコード ↗ は、特定の IP アドレスに対して許可されるホストを指定します。

Cloudflare では、PTR レコードは逆引き DNS ルックアップに使い、逆引きゾーン へ追加することを推奨します。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

Start of Authority（SOA）レコードは、管理者のメールアドレスやドメインの最終更新日時など、ドメインに関する情報を保存します。例は What is a DNS SOA record ↗ を参照してください。

権威 DNS に Cloudflare を使っている場合、SOA レコードを自分で作成する必要はありません。Cloudflare の権威ネームサーバーの利用を開始すると、このレコードは自動作成されます。

Enterprise アカウントでは、Cloudflare が使う SOA レコードの値を変更することもできます。

• DNS ゾーンのデフォルトとして: アカウントに追加するすべての新規ゾーンで Cloudflare が使う SOA レコード値を定義します。手順は DNS ゾーンのデフォルトを設定する を参照してください。
• 既存ゾーン向け: DNS Records ↗ ページの DNS record options で、デフォルトまたは Cloudflare 生成の値を上書きします。

各 SOA レコードフィールドの説明は、次の一覧を参照してください。

ネームサーバー（NS）レコード ↗ は、権威 DNS にどのサーバーを使うかを示します。

Cloudflare の DNS レコード表へ NS レコードを追加する必要があるのは、サブドメインセットアップ を使っている場合、または Cloudflare の外へサブドメインを委任 している場合だけです。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

NS レコードを作成するとき、1 つの委任名に関連付けられるネームサーバーの数には上限があります。

RFC 1912 ↗ で定義された DNS 標準では、同じ委任名の委任に含めるネームサーバー名は 7 個までとされています。

この標準に合わせ、プラットフォームの安定性を保つため、次の制限があります。

• Cloudflare は委任名あたり最大 10 件の NS レコードをサポートします。ただし、7 件以下に抑えるのがベストプラクティスです。
• 同じ名前に対して 10 件を超える NS レコードの作成はサポートしていません。この上限を超えるリクエストは拒否されるか、検証に失敗する場合があります。

DS と DNSKEY ↗ レコードは、DNS レコードに暗号署名を付けてドメインのなりすましを防ぐ DNSSEC の実装に使います。

ほとんどの Cloudflare ドメインでは、これらのレコードを追加する必要はなく、代わりに DNSSEC セットアップガイド に従ってください。

フィールド定義は、API ドキュメント を参照してください（リクエスト本文の仕様でレコードタイプを選ぶと表示されます）。

Cloudflare は、URI、NAPTR、証明書関連のレコードタイプ（SSHFP、TLSA、SMIMEA、CERT）など、あまり一般的でないレコードタイプにも対応しています。詳細は ブログ記事 ↗ を参照してください。