逆引き DNS（Reverse DNS）

概要

逆引き DNS（Reverse DNS） は、IP アドレスからドメイン名を解決する DNS の仕組みです。通常の DNS が「ドメイン名 → IP アドレス」の方向で名前解決を行う（正引き）のに対し、逆引き DNS は「IP アドレス → ドメイン名」の逆方向で解決します。RFC 1034 と RFC 1035（1987 年）で in-addr.arpa ドメインとともに定義され、IPv6 向けには RFC 3596（2003 年）で ip6.arpa ドメインが追加されました。

逆引き DNS は PTR レコードを使って動作します。PTR レコードの設定方法や管理権限の委任については PTR レコードの用語解説で詳しく扱っています。この記事では、逆引き DNS の概念的な仕組み、正引きとの違い、用途に焦点を当てます。

逆引き DNS の主な用途は 3 つあります。

• メールサーバーの送信元検証 — 受信サーバーが送信元 IP の正当性を確認する
• ネットワーク診断 — traceroute や nslookup で IP アドレスの代わりにホスト名を表示する
• アクセスログの可読性向上 — IP アドレスをホスト名に変換してログを読みやすくする

2025 年 11 月以降、Google（Gmail）は逆引き DNS（PTR レコードおよび FCrDNS）未設定のメールに対する拒否を段階的に強化しています。メール送信を行うサーバーでは逆引き DNS の設定が事実上の必須要件です。

仕組み

逆引き DNS は in-addr.arpa / ip6.arpa の専用名前空間と PTR レコードを使い、IP アドレスからホスト名を解決します。

正引きと逆引きの違い

正引き DNS と逆引き DNS は、名前空間の構造が根本的に異なります。

正引きでは、ドメイン名の階層がそのままゾーン委任の単位です。mail.example.com の A レコードは example.com ゾーンの管理者が設定します。一方、逆引きでは IP アドレスの管理者とドメインの管理者が別の組織であることが一般的です。IP アドレスブロックは IANA から地域インターネットレジストリ（APNIC、RIPE NCC、ARIN 等）へ、さらに ISP やホスティングプロバイダーへと割り当てられます。逆引きゾーンの管理権限もこの割り当てに沿って委任されるため、example.com の管理者が自分で逆引きを設定できるとは限りません。

項目	正引き DNS	逆引き DNS
方向	ドメイン名 → IP アドレス	IP アドレス → ドメイン名
使用するレコード	A / AAAA	PTR
ゾーン	ドメイン所有者が管理	IP アドレス割り当て元が管理
名前空間	ドメイン名の階層	in-addr.arpa / ip6.arpa
設定変更の権限	ドメイン管理者	IP ブロックの管理者（ISP 等）

in-addr.arpa と ip6.arpa

逆引き DNS は通常のドメイン名空間とは別に、専用のドメイン階層を使います。

IPv4 では in-addr.arpa ドメインを使用します。IP アドレスのオクテットを逆順に並べ、末尾に .in-addr.arpa を付与します。

IP アドレス:    203.0.113.1
逆引きクエリ:   34.216.184.93.in-addr.arpa.  →  PTR  mail.example.com.

オクテットを逆順にするのは、DNS の名前空間がルートから末端へ向かう階層構造だからです。IP アドレスはネットワーク部（上位ビット）からホスト部（下位ビット）へ並びますが、DNS はラベルの右側がルートに近い構造です。逆順にすることで、IP アドレスブロック単位でのゾーン委任が DNS の階層委任と一致します。

IPv6 では ip6.arpa ドメインを使用します。128 ビットのアドレスを完全展開し、16 進数の各ニブル（4 ビット = 1 桁）をドット区切りで逆順に並べます。

IPv6 アドレス:   2001:0db8::567:89ab
完全展開:        2001:0db8:0000:0000:0000:0000:0567:89ab
逆引きクエリ:    b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

IPv6 の逆引き名は 32 桁 のニブルで構成されるため、1 つのアドレスに対する逆引き名だけで 63 文字以上になります。IPv6 の巨大なアドレス空間（2^128 個）に対してすべての PTR レコードを事前に用意することは不可能です。RFC 8501（2018 年）は ISP 向けに、オンデマンド生成やワイルドカード PTR などの運用手法を整理しています。

クラスレス委任（RFC 2317）

IPv4 の逆引きゾーンは本来オクテット境界（/8、/16、/24）で委任されます。しかし、/24 より小さなブロック（/28 や /29 など）を割り当てられた場合、標準の仕組みでは委任ができません。

RFC 2317（1998 年）はこの問題に対処するため、CNAME レコードを使った委任手法を定義しました。上位ゾーンの管理者が個々の PTR エントリを CNAME で小ブロックの管理者のゾーンへ転送することで、オクテット境界に縛られない委任を実現します。

; /30 ブロック (192.0.2.128/30) の委任例
; 上位ゾーン (2.0.192.in-addr.arpa) の管理者が CNAME を設定
128.2.0.192.in-addr.arpa.  CNAME  128.128/30.2.0.192.in-addr.arpa.
129.2.0.192.in-addr.arpa.  CNAME  129.128/30.2.0.192.in-addr.arpa.

; 小ブロックの管理者が PTR を設定
128.128/30.2.0.192.in-addr.arpa.  PTR  host1.example.com.
129.128/30.2.0.192.in-addr.arpa.  PTR  host2.example.com.

正引きとの整合: FCrDNS

逆引き DNS が単体で存在しても、信頼性の証明としては不十分です。FCrDNS（Forward-Confirmed Reverse DNS）は、逆引きと正引きの双方向で整合性を検証する手法です。

1. IP アドレスの PTR レコードがホスト名を返す（逆引き）
2. そのホスト名の A または AAAA レコードが元の IP アドレスを返す（正引き）

この双方向が一致した状態が FCrDNS です。スパマーは乗っ取ったサーバーから送信するため PTR は設定できても、正引き側（A レコード）を一致させることができません。FCrDNS はこの非対称性を利用した信頼性検証です。

# FCrDNS の成立条件
203.0.113.1  →  PTR  →  mail.example.com.     (逆引き)
mail.example.com.  →  A  →  203.0.113.1       (正引き)
→ 双方向一致 = FCrDNS 成立

確認方法

特定の IP アドレスの逆引きを確認するには dig -x を使います。

# IPv4 の逆引き確認
dig -x 8.8.8.8

出力の ANSWER SECTION に PTR レコードが表示されます。

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.   7118   IN   PTR   dns.google.

IPv6 の逆引きも同じコマンドで確認できます。

# IPv6 の逆引き確認
dig -x 2001:4860:4860::8888

FCrDNS の検証は、逆引きで得たホスト名を正引きして元の IP と一致するかを確認します。

# 1. 逆引きでホスト名を取得
dig -x 203.0.113.1 +short

mail.example.com.

# 2. 正引きで IP を取得
dig A mail.example.com +short

203.0.113.1
→ 一致すれば FCrDNS 成立

外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ip?ip=8.8.8.8"

レスポンスの data.ptr フィールドに逆引き結果のホスト名が返ります。

{
  "success": true,
  "data": {
    "ip": "8.8.8.8",
    "type": "IPv4",
    "isPrivate": false,
    "ptr": "dns.google"
  },
  "error": null,
  "meta": { "responseTime": 42 }
}

PTR レコードが設定されていない IP アドレスでは ptr が null になります。ip パラメーターを省略すると、リクエスト元の IP アドレスに対する結果を返します。

よくある問題

逆引き DNS の設定では、PTR レコードと正引きの整合性、IPv4/IPv6 の両対応、反映タイミングに関するトラブルが発生します。

逆引きが設定されているのに FCrDNS が成立しない

逆引き DNS で PTR レコードが返っても、そのホスト名の A レコードが元の IP を指していないケースがあります。ホスティングプロバイダーがデフォルトで設定する PTR（例: vps-93-184-216-34.provider.com）は、対応する A レコードが存在しないことがあります。この場合、PTR をメール送信ドメインのホスト名（mail.example.com など）に変更し、A レコードと整合させます。

共有ホスティングで逆引きが設定できない

共有ホスティングでは 1 つの IP アドレスを複数のユーザーで共有しているため、個別に PTR レコードを変更できません。メール送信にはVPS や専用サーバーを使うか、SendGrid、Amazon SES などの ESP（Email Service Provider）を利用します。ESP は自社の送信 IP に適切な PTR レコードを設定済みで、SPF の include で許可する形式です。

IPv6 の逆引きが未設定

IPv4 の逆引きは設定していても、IPv6 の逆引きを忘れているケースがあります。メールサーバーが IPv6 でも送信する場合、IPv6 アドレスに対しても PTR レコードと FCrDNS を設定する必要があります。IPv6 のみ逆引きが欠落していると、IPv6 経由の送信だけが拒否される現象が発生します。dig -x で IPv4 と IPv6 の両方を確認してください。

逆引き結果の反映が遅い

PTR レコードも TTL でキャッシュされます。プロバイダーの管理画面で PTR を変更しても、旧 PTR の TTL が切れるまで古い値が返り続けます。メールサーバーの IP 移行時には PTR の TTL を事前に短縮しておくと、切り替え後の反映が速くなります。