IPアドレスの逆引きでは、PTRレコードに登録されたホスト名を確認できます。ただし、結果が空でも、そのIPが使われていないとは限りません。登録がない場合と、DNSへの問い合わせに失敗した場合を分けて読む必要があります。
まず調べたいIPをIPアドレス逆引きツールへ入力します。名前が返れば正引きで元のIPへ戻るかを確認し、返らなければ問い合わせの状態を調べます。ホスト名だけから利用者本人やアクセスの安全性まで判断しない方が良いです。
逆引きはサイトのURLを探す仕組みではない
正引きはホスト名からIPを調べ、逆引きはIPから登録された名前を調べます。この二つは別々のDNS情報です。WebサイトのAレコードを作成しても、PTRが自動で同じ名前になるとは限りません。
たとえば、複数サイトを収容するサーバーには一つの共通名が登録されている場合があります。逆引きで契約中のサイト名が出なくても、それだけで設定ミスではありません。そのIPで公開されている全サイトの一覧や、契約者の氏名が取得できるわけでもありません。
IPv4では in-addr.arpa、IPv6では ip6.arpa という逆引き用の名前空間を使います。名前を手で組み立てるより、次のようにIPを指定する方が間違いにくくなります。
digやnslookupで問い合わせる
ツールの表示だけでは原因を区別できないときは、DNS応答も確認します。次のIPは説明用です。実行時には調査対象のIPへ置き換えてください。
dig -x 203.0.113.10
nslookup 203.0.113.10
dig が使える環境では、結果の status と ANSWER SECTION を見ます。+short は名前だけを確認する際には便利ですが、失敗原因の調査では情報を省略しない通常出力を残します。BINDのdigマニュアルにも逆引きの -x オプションが記載されています。
利用するDNSサーバーを変えると結果が異なる場合があります。ただし、社内用IPや内部ホスト名を外部のDNSサービスへ送ってよいとは限りません。組織のネットワークでは、管理者が指定した照会先で確認してください。
PTRが見つからないときは応答を分ける
「逆引きできない」という表示だけでは、未登録なのか通信の問題なのかが分かりません。DNS応答が取得できるなら、まず次の違いを確認します。
| 応答・状態 | 読み取れること | 次に確認すること |
|---|---|---|
| PTRの名前が返る | その問い合わせでは名前を取得できた | 元のIPへ正引きできるか |
| NXDOMAIN | 問い合わせた名前が存在しないという応答 | 対象IPと逆引き側の登録・委任 |
| NOERRORだがPTRの回答がない | PTR未登録を示すNODATAの場合がある | SOAやCNAMEを含む応答全体 |
| SERVFAIL | DNS側で処理を完了できなかった | 権威DNSへの到達、委任、DNSSECなど |
| タイムアウト | 制限時間内に応答を得られなかった | 照会先、回線、DNS通信の制限 |
NODATAは独立した応答コードではありません。NOERROR で答えが空という一点だけで決めず、応答全体を見ます。NXDOMAINとの違いと、不在の情報もキャッシュされる仕組みはRFC 2308で定義されています。設定後も古い「登録なし」の応答が残る場合があるため、照会日時と照会先も記録します。
プライベートIPでは社内DNSにだけ逆引きが登録されている場合があります。外部ツールで名前が見えないことと、内部でも未設定であることは別です。SERVFAILやタイムアウトを見てPTRを作り直す前に、問い合わせ自体が成立しているかを確認してください。
名前が返ったら正引きと照合する
返されたホスト名のAレコード、IPv6ならAAAAレコードを確認し、最初に調べたIPが含まれるかを見ます。次は正逆が対応している仮の例です。
逆引き: 203.0.113.10 → mail.example.com
正引き: mail.example.com → 203.0.113.10
この確認はFCrDNSと呼ばれます。メール送信では、実際に外部へ接続する送信元IPで確認することが重要です。WebサイトのIPや、受信先を示すMXレコードだけを調べても、送信経路の確認にはなりません。Gmailの送信者ガイドラインは、送信元IPのPTRと、その名前のAまたはAAAAが対応することを求めています。
メール配信サービスを利用している場合、送信元IPのPTRは通常そのサービス側の管理範囲です。自社ドメインのDNSを変更する前に、エラーメールに記載されたIPと利用サービスを照合し、必要ならサポートへ確認します。
PTRの変更を依頼する相手
公開IPの逆引きは、通常そのIPを管理する回線事業者やホスティング事業者へ確認します。管理画面で利用者が変更できるサービスや、逆引きゾーンを委任されている環境もあります。ドメインを購入した会社へ依頼すれば必ず変更できる、というものではありません。
AWSの逆引きDNSに関する案内でも、意図した逆引き結果にならない場合はIPの管理者へ確認するよう説明されています。問い合わせには対象IPと希望するホスト名を伝え、現在の応答と確認日時を添えます。希望名の正引きが対象IPを指していることも、先に確かめておくと話が進みやすいです。
逆引き結果だけで安全性を判定しない
有名サービスに似た名前が返っても、正規のアクセスである証明にはなりません。逆にPTRがないIPを、一律に攻撃元として遮断するのも避けます。判定したいのがメール、検索クローラー、一般のWebアクセスなのかで必要な情報が違うためです。
たとえばGoogleからのアクセス確認では、Google公式の確認方法に従い、逆引き名の所定のドメインと正引きの一致などを確認します。単にホスト名へ google が含まれるだけでは不十分です。
まずは一つのIPについて、PTRの結果とDNS応答を残してください。メールの配信問題なら、その次にメールヘッダーの読み方を参考に実際の送信経路を照合します。登録がない問題と取得できない問題を分けることで、変更する設定と相談先を絞れます。