PTRレコードを設定したのに dig -x で何も返らない、または古いホスト名のままというときは、まず「設定した場所が、そのIPアドレスの逆引きを実際に管理しているDNSか」を確かめます。反映待ちと思われがちですが、実際には設定場所の取り違え、逆引きゾーンの委任の不足、ゾーンファイルの書き方の誤りが原因であることが少なくありません。この記事では、DNS側で逆引きが引けないときの切り分け手順と、多い原因から順に確認方法と直し方を説明します。メールの受信側で逆引きエラーが出る場合の確認は、別の記事で扱っています。
まず症状を3つに分ける
最初に、どこで何が返っているかを確認します。
# 一般のリゾルバでの結果
dig -x 203.0.113.25 +short
# 逆引きゾーンを管理しているネームサーバーを調べる
dig 113.0.203.in-addr.arpa NS +short
# そのネームサーバーに直接問い合わせる（キャッシュの影響を受けない）
dig -x 203.0.113.25 @ns1.example-isp.net +norecurse結果は、だいたい次の3つのどれかに当てはまります。
- 権威サーバーでも何も返らない（NXDOMAIN や回答なし）: 設定場所か書き方の問題です
- 権威サーバーでは新しい値、リゾルバでは古い値: キャッシュが残っているだけなので、旧レコードのTTLが切れるのを待ちます
- 権威サーバーでも古い値: 変更が保存・読み込みされていないか、編集したのが別のサーバーです
この切り分けを先にしておくと、原因の候補を大きく減らせます。
原因1：自分のドメインのDNSにPTRを書いている
もっとも多い誤りです。逆引きの名前（25.113.0.203.in-addr.arpa）は、IPアドレスの割り当てに沿って委任されています。自分のドメインを管理しているDNSサービスの画面でPTRを作っても、そのサービスは in-addr.arpa の委任を受けていないため、誰からも参照されません。
確認方法は、上の dig 113.0.203.in-addr.arpa NS +short です。返ってきたネームサーバーがVPSやクラウドの事業者のものなら、事業者の管理画面かAPI、またはサポートへの申請で設定します。自分のドメインのDNSに作ったPTRは消しておくと、後で混乱しません。
原因2：逆引きゾーンが自分のサーバーに委任されていない
自前のBINDなどで逆引きゾーンを作ったのに引けない場合、そのゾーンが上位から委任されていない可能性があります。自分のサーバーに直接問い合わせると答えが返るのに、dig 113.0.203.in-addr.arpa NS で自分のサーバーが出てこないなら、この状態です。
委任は、IPアドレスを割り当てた事業者（上位のISPやデータセンター）が行います。事業者に、逆引きゾーンを自分のネームサーバーへ委任してもらうよう依頼します。割り当てが /24 より小さい場合（/28 など）は、オクテットの区切りで委任できないため、RFC 2317 の方式で、事業者側にCNAMEを置いてもらう形になります。
; 事業者側（203.0.113.0/24 のゾーン）に置いてもらう例
16/28 IN NS ns1.example.com.
25 IN CNAME 25.16/28.113.0.203.in-addr.arpa.
; 自分の側のゾーン（16/28.113.0.203.in-addr.arpa）
25 IN PTR mail.example.com.この方式は名前の付け方（16/28 や 16-28 など）を事業者に合わせる必要があります。自分だけで決めずに、事業者の指定に従ってください。
原因3：ゾーンファイルの書き方の誤り
自前のゾーンで多いのが、末尾のドットの付け忘れです。ゾーンファイルでは、ドットで終わらない名前にゾーン名が自動で付け足されます。
; 誤り：末尾のドットが無い
25 IN PTR mail.example.com
; → mail.example.com.113.0.203.in-addr.arpa. と解釈される
; 正しい書き方
25 IN PTR mail.example.com.dig -x の結果が mail.example.com.113.0.203.in-addr.arpa. のような長い名前になっていたら、これが原因です。
ほかに、次の誤りもよく見かけます。
- ゾーン名の並びを逆にし忘れる:
203.0.113.in-addr.arpaではなく113.0.203.in-addr.arpaが正しい形です - 左側にIPアドレス全体を書く: ゾーンが
113.0.203.in-addr.arpaなら、左側は最後のオクテット（25）だけです named.confのゾーン定義とファイル名の不一致: 定義したゾーンと別のファイルを編集している場合があります
書き方は named-checkzone で確かめられます。
sudo named-checkzone 113.0.203.in-addr.arpa /etc/bind/db.203.0.113
sudo named-checkconf原因4：保存・読み込み・転送のどこかで止まっている
権威サーバーでも古い値が返る場合は、変更が配信されていません。次の順に確認します。
- SOAのシリアル番号を上げたか。上げないと、セカンダリのサーバーが更新を取りに来ません
rndc reload 113.0.203.in-addr.arpaなどで読み込み直したか。エラーはシステムログ（journalctl -u namedなど、環境によりサービス名は異なります）に出ます- プライマリとセカンダリで同じ値を返しているか。NSに登録したすべてのサーバーに問い合わせて比べます
for ns in $(dig 113.0.203.in-addr.arpa NS +short); do
echo "== $ns"
dig -x 203.0.113.25 @"$ns" +norecurse +short
dig 113.0.203.in-addr.arpa SOA @"$ns" +short
doneシリアル番号がサーバーごとに違えば、転送が止まっています。ゾーン転送の許可設定（allow-transfer）や、セカンダリ側のログを確認します。事業者の画面で設定した場合は、保存の操作が完了しているか、反映に時間がかかる仕様かを事業者のドキュメントで確かめます。
原因5：IPアドレスの取り違え
意外に多いのが、設定したIPと調べているIPが違うケースです。サーバーに複数のIPがある、Elastic IP などの付け替えをした、IPv4とIPv6の両方を持っている、といった環境で起こります。サーバーの外向きのIPを確認し、そのIPで dig -x を引き直します。事業者の画面で、別のサーバーやIPの欄に入力していないかも確認します。
修正後の確認
修正したら、権威サーバーで新しい値が返ることを確かめ、その後に一般のリゾルバでも確かめます。
dig -x 203.0.113.25 @ns1.example-isp.net +norecurse +short
dig -x 203.0.113.25 @1.1.1.1 +short
dig -x 203.0.113.25 @8.8.8.8 +short権威サーバーで正しく、リゾルバでだけ古い場合は、旧レコードのTTL分待ちます。何も返らない状態（NXDOMAIN）がキャッシュされている場合は、逆引きゾーンのSOAから決まる時間だけ否定応答が残ります。設定変更の前には、現在の値とゾーンファイルを控えておくと、元に戻すときに困りません。事業者の画面の項目名や受付方法は変わることがあります（2026年10月現在）。
まとめ
- 一般のリゾルバ、委任先のNS、権威サーバーへの直接問い合わせの3つで、設定ミスかキャッシュかを切り分ける
- 自分のドメインのDNSに書いたPTRは参照されない。設定場所は
in-addr.arpaのNSで確かめる - 自前ゾーンは委任の有無、末尾のドット、ゾーン名の並び、左側の書き方を確認し、
named-checkzoneを通す - シリアル番号の更新と読み込み直し、全NSで同じ値かを確かめる
- 設定したIPと、実際に使っているIPが同じかも見直す