2026年6月16日
2026年6月16日
delv コマンドで逆引きする方法|複数の IP をまとめて調べる手順と、+rtrace で逆引きゾーンの委任をたどる見方
delv で逆引きするには delv -x IPアドレス を実行します。delv は PTR の値と一緒に「その答えが DNSSEC で検証できたか」を先頭の1行で示すため、逆引きの設定確認と、逆引きゾーンが署名されているかの確認を同時に行えます。この記事では、基本の形を押さえたうえで、メール送信に使う複数の IP やアクセスログの IP をまとめて調べるスクリプト、+rtrace と +vtrace で逆引きゾーンの委任のつながりと管理者をたどる方法を説明します。
逆引きの名前は「割り当ての階層」をたどる
逆引きでは、IP アドレスを逆順に並べた名前の PTR レコードを引きます。203.0.113.25 なら 25.113.0.203.in-addr.arpa、IPv6 なら ip6.arpa の下に16進数1桁ずつ逆に並べた名前です。
この名前の階層は、IP アドレスの割り当ての流れと対応しています。ルートの下に arpa、その下に in-addr.arpa があり、そこから地域のインターネットレジストリ(アジア太平洋なら APNIC、日本国内では JPNIC が関わることもあります)、プロバイダーやサーバー事業者へと委任が続き、最後に個々の IP の PTR が置かれます。逆引きの設定ができるのはこの委任の末端にいる事業者で、ドメインの DNS 管理画面に PTR を書いても逆引きには効きません。
DNSSEC の観点では、arpa と in-addr.arpa は署名されており、レジストリの逆引きゾーンも署名されていることが多い一方、その先のプロバイダーや事業者のゾーンは署名されていないことが少なくありません。delv の結果が ; unsigned answer になりやすいのはこのためで、「途中から署名の無いゾーンに委任されている」という意味です。逆引きの設定が誤っているという意味ではありません。
基本の形
delv は BIND に付属するコマンドで、Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils に入っています。
delv -x 203.0.113.25 # IPv4
delv -x 2001:db8::25 # IPv6(省略形のまま渡せる)
delv @1.1.1.1 -x 203.0.113.25 # 問い合わせ先のキャッシュサーバーを指定
delv -x 203.0.113.25 +nodnssec # 署名(RRSIG)の行を省く
-x を使うと、逆順の名前の組み立てと PTR の指定を delv が代わりに行います。IPv6 は32桁の名前になるため、手で組み立てると桁を取り違えやすく、-x に任せるのが安全です。
結果は、1行目の検証結果と、その下の PTR の行で読みます。; fully validated は署名のつながりをルートから確認できた答え、; unsigned answer は署名の無いゾーンからの答え、PTR の行が無く否定や失敗のメッセージだけが出る場合は、PTR が無いか、途中で問い合わせに失敗しています。メッセージの文言は BIND の版によって異なります。
複数の IP をまとめて調べる
WordPress を運用していると、ウェブサーバー、メール送信用のサーバーやリレー、移転前後のサーバーなど、逆引きを確かめたい IP が複数になることがあります。1件ずつ打つ代わりに、IP の一覧を読み込んで「検証結果・PTR・正引きとの一致」を表にするスクリプトを用意しておくと、移転作業の前後で同じ確認を繰り返せます。
#!/usr/bin/env bash
# 使い方: ./rdns-check.sh ips.txt
# ips.txt には1行に1つの IP アドレスを書く(IPv4・IPv6 を混ぜてもよい)
resolver="${RESOLVER:-1.1.1.1}"
printf 'IP\t検証結果\tPTR\t正引き\n'
while IFS= read -r ip; do
[ -z "$ip" ] && continue
out=$(delv @"$resolver" -x "$ip" +nodnssec 2>&1)
status=$(printf '%s\n' "$out" | grep -m1 '^;' | sed 's/^;* *//')
ptr=$(printf '%s\n' "$out" | awk '$4 == "PTR" { print $5; exit }')
fwd="-"
if [ -n "$ptr" ]; then
case "$ip" in *:*) t=AAAA ;; *) t=A ;; esac
if delv @"$resolver" "$ptr" "$t" +short +nodnssec 2>/dev/null | grep -v '^;' | grep -qFx "$ip"; then
fwd="一致"
else
fwd="不一致"
fi
fi
printf '%s\t%s\t%s\t%s\n' "$ip" "${status:-不明}" "${ptr:-なし}" "$fwd"
sleep 0.2
done < "$1"
PTR の行は「名前、TTL、クラス、種別、値」の順に並ぶため、4列目が PTR の行の5列目を値として取り出しています。RFC 2317 の方式で逆引きが CNAME を経由している場合も、CNAME の行の後に続く PTR の行を拾います。正引きの欄は、得たホスト名の A(IPv6 なら AAAA)に元の IP が含まれるかを見ています。メールの受信側の多くはこの「逆引きと正引きの一致」を確認するため、メール送信に使う IP では「一致」になっているのが望ましい状態です。
使うときの注意点は次のとおりです。
- IPv6 の表記:一致の判定は文字列で比べるため、一覧の IPv6 は省略形(
2001:db8::25の形)で書きます。ゼロを省略しない形で書くと、正しく設定されていても「不一致」と表示されます。 - 問い合わせの間隔:
sleep 0.2は、公開のキャッシュサーバーに短時間で大量の問い合わせを送らないための間隔です。数百件を調べる場合は、自前のキャッシュサーバーを使うか間隔を広げます。 - アクセスログの IP を扱う場合:IP アドレスは個人に結びつく情報として扱われることがあります。調べた結果のファイルは目的を終えたら削除し、サイトのプライバシーポリシーの範囲内で扱ってください。
結果が「なし」の IP は、PTR が未設定か、設定が反映される前の状態です。設定の窓口は IP を割り当てている事業者の管理画面かサポートで、名称は「逆引き」「リバース DNS」など事業者によって異なります。
+rtrace で逆引きゾーンの委任をたどる
PTR を直したいのに、どの事業者のゾーンなのかが分からないことがあります。+rtrace を付けると、delv が答えを得るまでに取りに行ったレコードの一覧が表示され、どのゾーンを経由したかが見えます。
delv -x 203.0.113.25 +rtrace
出力には、問い合わせた名前と種別が1件ずつ記録されます(行の書式は版によって異なります)。PTR の名前のほか、in-addr.arpa やその下のゾーンの DS・DNSKEY を取りに行った記録が並び、途中で DS を取りに行って「無い」と分かったところが、署名の無いゾーンへの委任の境目です。より詳しく、送受信したメッセージの中身まで見たいときは +mtrace を使います。
管理しているゾーンを特定するには、逆引きの名前を上から順に SOA で引くと分かりやすくなります。
delv -t SOA 113.0.203.in-addr.arpa +nodnssec
delv -t SOA 0.203.in-addr.arpa +nodnssec
SOA が返った名前がそのゾーンの頂点で、SOA の1つ目の値(プライマリーのネームサーバー)や2つ目の値(管理者の連絡先)から、どの事業者が管理しているかの見当がつきます。小さなアドレスブロックを借りている場合は、/24 のゾーンは上位の事業者が持ち、その中の一部だけが CNAME で利用者側に振り向けられていることもあります。
+vtrace で「どこから署名が無いのか」を見る
+vtrace は検証の過程を表示する指定で、各ゾーンの検証が成功したのか、署名が無いことが証明されたのかが記録されます。
delv -x 203.0.113.25 +vtrace
逆引きで ; unsigned answer が出たとき、+vtrace を見ると、どのゾーンで「署名が無い(insecure)」と判断されたかが分かります。自分で逆引きゾーンを運用していて DNSSEC を導入したつもりなのに unsigned answer になる場合は、親ゾーン側に DS が登録されていないことが主な原因です。逆引きゾーンの DS は、ドメインのレジストラではなく、アドレスを割り当てたレジストリや上位の事業者に登録を依頼します。
反対に、検証に失敗して PTR が表示されない場合は、-i で検証を止めた結果と比べます。-i を付けたときだけ PTR が返るなら、署名の期限切れや DS と鍵の不一致など、逆引きゾーンの DNSSEC の問題です。
つまずきやすい点
- 手元のスタブリゾルバー経由で失敗する:問い合わせ先が
127.0.0.53などのスタブリゾルバーだと、検証に必要なレコードを受け取れずに失敗することがあります。@1.1.1.1のように外部のキャッシュサーバーを指定して比べます。新しい版の delv には、外部のキャッシュサーバーを使わずに delv 自身がルートから名前解決する+nsという指定もあります(2026年10月現在)。BIND 9.20 系の delv にある機能で、古い版にはありません。手元のdelv -hで使えるかを確かめてください。 - 権威サーバーを @ で指定する:delv に権威サーバーを指定すると、検証に必要な親ゾーンの情報もそのサーバーに求めるため、失敗しやすくなります。権威サーバーの生の値は dig や host で確かめ、delv は検証結果を見るために使うと整理しやすくなります。
- 古い delv のトラストアンカー:長く更新していない環境では、組み込みのルートの鍵が現在のものと合わず、検証に失敗することがあります。OS のパッケージを更新してから使います。
まとめ
delv -x IPアドレスで、IPv4・IPv6 の逆引きと DNSSEC の検証結果を一度に確かめられます。- 逆引きゾーンは途中から署名が無いことが多く、
; unsigned answerは正常な結果です。 - 複数の IP は、PTR と正引きの一致をまとめて表にするスクリプトで確かめると、移転前後の比較がしやすくなります。
+rtraceと SOA の問い合わせで逆引きゾーンの管理者を、+vtraceで署名が途切れる位置を確かめます。- 検証に失敗したら
-iと比べ、DNSSEC の問題かどうかを切り分けます。