こんにちは！NOC（ネットワークオペレーションセンター）で日々、数々のネットワークの嵐と格闘しているシニアエンジニアです。
データセンターの深夜、突然鳴り響くアラート音。「またか……」とコーヒーを一口飲んでディスプレイに向かうと、そこにあるのは決まってセキュリティログのエラーや、メールが届かないという悲鳴のようなチケットです。こうした現場のトラブルで、意外と多くのエンジニアが頭を悩ませるのが、今回取り上げる「DNS逆引き（PTRレコード）」の不整合なんですよね。
「名前からIPアドレスを引く（正引き）」のは普段からよく使うと思いますが、「IPアドレスから元の名前を引っ張り出す（逆引き）」というのは、少し裏方っぽくて敬遠されがちです。でも、メールサーバーの運用やセキュリティの厳格化が進む現代のインフラにおいて、この逆引きを制することは、トラブルシューティングの強力な武器になります。
今回は、ネットワークの世界に足を踏み入れたばかりのあなたへ向けて、身近な例えを交えながら、この逆引き調査と不整合の特定方法を優しく、そして泥臭く紐解いていきましょう！
—
1. 逆引き（PTRレコード）ってなに？郵便配達に例えてみよう
普段、私たちはWebサイトを見る時に www.example.com のような「ホスト名」を使いますよね。これをコンピュータが分かる 192.0.2.1 のような「IPアドレス」に変換する仕組みを正引き（Aレコード）と言います。電話帳で名前から電話番号を探すようなものです。
では、その逆である逆引き（PTRレコード）はどうでしょう？
これは、届いた手紙の差出人欄に書かれた「住所（IPアドレス）」を見て、「本当にその住所にその名前の人が住んでいるか？」を確認する作業に似ています。
なぜ逆引きが必要なの？
現代のインターネット、特にメールサーバーの世界では、この逆引きがめちゃくちゃ重要視されます。
あなたが宛先にメールを送ったとき、受け取り側のサーバーはこう考えます。
「お、 203.0.113.50 という住所からメールが届いたぞ。どれどれ、本当にこの住所の主は mail.company.com さんかな？ 詐欺じゃないよな？」
ここで、IPアドレスからホスト名を調べた結果（逆引き）と、そのホスト名から再びIPアドレスを調べた結果（正引き）が一致しないと、受け取り側のサーバーは「うわ、なんだか怪しいぞ！スパムに違いない！」と判断して、メールを受け取ってくれないのです。これが、インフラ現場でよくある「逆引き不整合エラー」の正体です。
—
2. 現場で使う診断コマンド：dig と nslookup を使いこなそう
それでは、実際に手元の端末からこの「住所と名前の食い違い」を暴く方法を見ていきましょう。一歩ずつ、コマンドを叩いていけば怖くありませんよ！
① まずはIPアドレスから名前を引いてみる（PTR調査）
IPアドレス 192.0.2.123 のホスト名を知りたいときは、dig コマンドの -x（逆引き用オプション）を使います。
# IPアドレス 192.0.2.123 の逆引き（PTRレコード）を調べる
dig -x 192.0.2.123 +shortこのコマンドを実行したとき、例えば mail.example.com. というホスト名が返ってきたとします。おや、ちゃんと名前が出てきましたね。
② 返ってきた名前が本当に正しいか「お代わり正引き」をする
ここで安心してはいけません。悪意ある誰かが、勝手に他人のIPアドレスに対して適当な逆引き設定（PTRレコード）を書き換えている可能性があるからです。
先ほど得られた mail.example.com が、本当に再び元の 192.0.2.123 を指しているか、今度は通常の正引きで確認します。これをインフラ業界では「正逆一致確認（Forward-Confirmed Reverse DNS: FCrDNS）」と呼びます。
# 得られたホスト名から、再度IPアドレスを引いてみる（正引き）
dig A mail.example.com +shortここで出力されたIPアドレスが、最初に調査した 192.0.2.123 と完全一致していれば合格です！しかし、もし 192.0.2.99 だったり、何も返ってこなかったりした場合は……「不整合（エラー）」の判定となります。
—
3. 実践！メールサーバーの逆引き不整合を特定するシナリオ
ある日、自社のメールサーバーから送信したメールが、主要なフリーメールサービスに弾かれるというトラブルが発生したと仮定しましょう。NOCルームのモニタリング画面には、以下のようなログが流れています。
> Status: 550 5.7.1 Service unavailable; Client host [203.0.113.15] blocked using Spamhaus あるいは PTR record mismatch
焦らず、以下のステップで原因を特定していきます。
ステップ1：自社サーバーの外部IPを確認する
まずは、自分が外の世界からどう見えているかを確認します。複数回線を持つデータセンターなどでは、送信に使っているグローバルIPが想定と違うこともよくあります。
ステップ2：逆引きと正引きのループを検証する
ターミナルを開き、以下のコマンドを連続して実行してみましょう。
# 1. 逆引き（PTR）の確認
dig -x 203.0.113.15 +short
# 出力結果例: sv1.my-domain.co.jp.
# 2. 得られたホスト名での正引き（A）の確認
dig A sv1.my-domain.co.jp +short
# 出力結果例: 203.0.113.99 （あれっ、違うIPが出てきた！）【診断結果】
おっと、逆引き結果は sv1.my-domain.co.jp なのに、その名前を正引きすると 203.0.113.99 という全く別のIPアドレスが返ってきました。送信元IPである 203.0.113.15 と一致しません。
これがまさに、メール不達を引き起こしていた「逆引き不整合（PTRミスマッチ）」です！
ステップ3：どうやって直すの？（根本的な解決策）
この不整合を直すには、ネットワーク機器のコンフィグやサーバーの設定ではなく、ドメインの管理（DNSゾーンファイル）、あるいはIPアドレスを借りているプロバイダ（ISP）の逆引きゾーン設定を修正する必要があります。
1. 自社でDNSを管理している場合：
正引きゾーンにおいて、sv1 のレコードが正しいIP（203.0.113.15）を向くように修正します。
2. IPアドレスをプロバイダから割り当てられている場合：
プロバイダの担当窓口に連絡し、「我が社のIP 203.0.113.15 に対する逆引きPTRレコードを、確実に sv1.my-domain.co.jp に向けて登録してください」と依頼（逆引き委任の設定変更）します。
—
4. さいごに
ネットワークのトラブルシューティングは、時として「犯人探しのミステリー小説」のようです。一見すると難解なエラーメッセージも、今回紹介したように「住所と名前の照合（正逆一致）」という基本のルールに立ち返って dig コマンドで一つずつ紐解いていけば、必ず真実の姿が見えてきます。
「あれ、名前とIPが噛み合っていないぞ？」という違和感に気づける嗅覚こそが、優れたエンジニアの第一歩です。
日々の運用監視の中で、ぜひ怖がらずにコマンドを叩いて、パケットたちの声に耳を傾けてみてくださいね。それでは、また次回の現場でお会いしましょう！
コメント