皆さん、こんにちは！NOCシニアエンジニアの○○（NOCのトップエンジニアの名前、任意で想像）です。今日もパケットがネットワークを駆け巡るリアルな現場から、皆さんのインフラ理解を深めるためのとっておきの知恵をお届けしますよ。
我々NOCエンジニアにとって、ネットワークのトラブルシューティングはまさに「探偵仕事」。日々、様々なヒントを頼りに問題の根源を探し当てています。その探偵道具の中でも、digコマンドは特に強力なツールの一つ。以前の記事では、ホスト名からIPアドレスを調べる「正引き」について解説しましたよね。
今回は、その逆！ 「IPアドレスはわかってるんだけど、このIPアドレスを使ってるサーバーの名前って何だっけ？」 という疑問に答えるための、「逆引き」 について徹底解説していきます。
「逆引き？何それ、おいしいの？」と思ったあなた、大丈夫！ネットワークの世界に初めて足を踏み入れる方も、一歩ずつ理解していきましょう！
—
郵便配達で例える「正引き」と「逆引き」
まずは、日常生活に例えて「正引き」と「逆引き」の概念をスッキリ理解しましょう。
正引き：名前から住所を探す
あなたが友人に手紙を送るとします。友人の「名前」は知っているけど、「住所」が分からない。そんな時、どうしますか？
普通は、電話帳やインターネットで友人の「名前」を検索して「住所」を調べますよね。これがネットワークの世界でいう 「正引き（Forward Lookup）」 です。
- 名前（ホスト名）:
www.example.com - 住所（IPアドレス）:
192.0.2.1
ネットワークでは、dig www.example.com とコマンドを打って、ホスト名からIPアドレスを調べるのがこれにあたります。
逆引き：住所から名前を探す
では、逆に「住所」は知っているけど、「誰が住んでいるのか名前」が分からない場合はどうでしょう？
例えば、差出人不明の手紙が届いた時、住所から送り主の名前を特定しようとしますよね。あるいは、ある住所に「誰が住んでいるのか」を確認したい時。これがネットワークの世界でいう 「逆引き（Reverse Lookup）」 です。
- 住所（IPアドレス）:
192.0.2.1 - 名前（ホスト名）:
server01.example.com
「なんでそんなことするの？」と思うかもしれませんが、これがトラブルシューティングの現場ではとんでもなく役立つんです。例えば、サーバーのログに不審なIPアドレスが記録されていた時、そのIPアドレスがどのホスト名を持つサーバーなのかが分かれば、一気に調査が進みますからね。
—
逆引きを司る「PTRレコード」と特別なドメイン
ネットワークの世界で逆引きを行うためには、「PTRレコード」という特別な情報が必要です。そして、それを管理するための「特別なドメイン」も登場します。
PTRレコード：住所録に書かれた「住人の名前」
DNS（Domain Name System）には、様々な種類のレコードがあります。正引きに使われるAレコード（IPv4アドレス）やAAAAレコード（IPv6アドレス）が有名ですよね。
逆引きに使われるのが PTRレコード (Pointer Record) です。これはまさに、「このIPアドレスには、このホスト名が対応していますよ」という情報を指し示す、特別な「住人の名前が書かれた札」のようなものです。
in-addr.arpa と ip6.arpa：逆引き専用の特別な住所帳
さて、IPアドレスからホスト名を調べるということは、通常のドメイン名（example.comなど）とは少し違う仕組みが必要です。そこで登場するのが、in-addr.arpa ドメインと ip6.arpa ドメインです。
これらは、逆引きのためだけに存在する、いわば「逆引き専用の特別な住所帳」のようなもの。
そして、ここが少し面白いのですが、IPアドレスは逆順にしてこのドメインに付け加えられます。
- IPv4アドレス の場合:
例えば 192.168.1.100 というIPアドレスの逆引きをしたい場合、DNSに問い合わせるのは 100.1.168.192.in-addr.arpa というドメイン名になります。
「なんで逆順なの？」って思いますよね。これは、IPアドレスの階層構造をDNSのドメイン階層に合わせるためなんです。一番右側の数字（例でいう100）が、そのIPアドレスの「末端」を指す、とイメージしてください。
- IPv6アドレス の場合:
IPv6アドレスも同様に逆順になり、さらに各オクテット（2桁の16進数）ごとにドットで区切られ、ip6.arpa ドメインに付け加えられます。
例えば 2001:db8::1 のようなアドレスは、1.0.0.0.0.0.0.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 のように非常に長くなります。
これはもう、郵便番号を逆から書いて、さらに細かく区切って住所にするようなもの、とでも想像してください。ちょっと複雑ですが、これがグローバルなDNSシステムの中で、どの範囲のIPアドレスを誰が管理しているかを効率的に見つけるための賢い仕組みなんです。
—
digコマンドで逆引きを実践してみよう！
それでは、実際にdigコマンドを使って逆引きを試してみましょう。digコマンドで逆引きを行うには、-x オプションを使います。
基本的な逆引きクエリ
まずは、皆さんもよくご存じのGoogle Public DNSのIPアドレスを逆引きしてみましょう。
dig -x 8.8.8.8コマンド解説
dig: DNS情報を問い合わせるコマンドです。-x: これが「逆引き」を指定するオプションです。この後にIPアドレスを続けます。8.8.8.8: Google Public DNSのIPv4アドレスです。
実行結果の例
; <<>> DiG 9.16.1-Ubuntu <<>> -x 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37774
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa. IN PTR
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa. 21599 IN PTR dns.google.
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 10:00:00 JST 2023
;; MSG SIZE rcvd: 66出力結果の読み解き方
出力結果を上から順に見ていきましょう。
1. QUESTION SECTION:
;8.8.8.8.in-addr.arpa. IN PTR- 「私は
8.8.8.8の逆引きを知りたいです」という問い合わせの内容が示されています。IPアドレスが逆順になってin-addr.arpaが付いているのが分かりますね。
2. ANSWER SECTION:
8.8.8.8.in-addr.arpa. 21599 IN PTR dns.google.- ここが知りたい情報です！
IN: インターネットクラスのレコードであることを示します。PTR: このレコードがPTRレコードであることを示します。dns.google.: これが8.8.8.8に対応するホスト名です！
これで 8.8.8.8 が dns.google というホスト名を持っていることが分かりましたね！
IPv6アドレスの逆引きも同様
IPv6アドレスの逆引きも -x オプションを使います。
# 例: Google Public DNSのIPv6アドレス
dig -x 2001:4860:4860::8888結果を見ると、8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. のような非常に長いドメイン名に対する PTR レコードが表示されるはずです。
—
現場でよくある！逆引きが失敗するケースとその原因
さて、ここからがNOCエンジニアとしての腕の見せ所。逆引きがいつも綺麗に成功するとは限りません。むしろ、「あれ？逆引きできないぞ？」という状況に遭遇することの方が、トラブルシューティングの現場では多いかもしれません。
逆引きが失敗する主な原因を、郵便配達の例えを交えながら見ていきましょう。
1. PTRレコードが存在しない（住人の名前が名簿にない）
最も一般的なケースです。IPアドレスの管理者が、そのIPアドレスに対応するPTRレコードをDNSサーバーに設定していない場合、逆引きは失敗します。
状況の例
# 例: プライベートIPアドレス (通常、インターネット上のDNSには設定されていません)
dig -x 192.168.1.100実行結果の例
; <<>> DiG 9.16.1-Ubuntu <<>> -x 192.168.1.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;100.1.168.192.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 10:05:00 JST 2023
;; MSG SIZE rcvd: 104出力結果の読み解き方
status: NXDOMAIN: これがポイントです！NXDOMAINは「No such Domain」の略で、「そのようなドメインは存在しません」という意味になります。つまり、「そのIPアドレスに対応するPTRレコードは見つかりませんでした」というエラーです。ANSWER: 0: 回答セクションにレコードが一つもありませんね。
これは、郵便局の特別名簿に、その住所の住人の名前が載っていなかった、という状況に似ています。
なぜ設定しないのか？:
全てのIPアドレスにPTRレコードを設定する必要はありません。特に、インターネットに直接公開されないプライベートIPアドレス（192.168.x.xなど）や、動的に割り当てられるIPアドレスでは設定されていないことがほとんどです。セキュリティやプライバシーの観点から、あえて設定しないケースもあります。
2. IPアドレスブロックのゾーン委任が適切でない（担当の郵便局が間違っている）
ここが、今日のテーマの肝となる部分です！DNSは世界中に分散している巨大なデータベースで、それぞれのドメインやIPアドレスブロックの管理は、適切なDNSサーバーに「委任」されています。逆引きの in-addr.arpa や ip6.arpa ドメインも例外ではありません。
ゾーン委任とは？
例えば、example.com の管理は example.com のDNSサーバーに委任されています。同様に、特定のIPアドレス範囲（例: 192.0.2.0/24）の逆引き情報（2.0.192.in-addr.arpa）の管理も、そのIPアドレスを所有する組織のDNSサーバーに委任されている必要があります。
この委任が正しく行われていないと、問い合わせを受けたDNSサーバーは「このIPアドレスの逆引きは、誰に聞けばいいか分からない！」となり、正しい情報にたどり着けません。これは、「この地域の手紙のことは、担当の郵便局に聞いてねって言われてるんだけど、その担当の郵便局がどこだか知らない！」という状況です。
ゾーン委任の問題を確認する方法: dig +trace
digコマンドの +trace オプションを使うと、DNSサーバーがどのように問い合わせを解決していくか、その「旅路」を追跡することができます。これにより、どこで委任が途切れているか、どこに問題があるかを探ることができます。
# 例: 8.8.8.8 の逆引きのトレース
dig -x 8.8.8.8 +trace実行結果の読み解き方
非常に長い出力になりますが、ポイントは以下の通りです。
1. まず、ルートDNSサーバー (.) に問い合わせ、arpa ドメインのNS（ネームサーバー）レコードを見つけます。
2. 次に、arpa ドメインのNSに問い合わせ、in-addr.arpa ドメインのNSレコードを見つけます。
3. さらに、in-addr.arpa のNSに問い合わせ、8.8.8.in-addr.arpa のような、より具体的なIPアドレスブロックのNSレコードを見つけます。
4. 最終的に、そのIPアドレスブロックを管理しているDNSサーバーに問い合わせが到達し、PTRレコードが返されます。
もし途中で status: REFUSED や SERVFAIL が出たり、期待するNSレコードが見つからなかったりする場合は、どこかの段階でゾーンの委任が適切に行われていない可能性があります。これは、上位のプロバイダやレジストリが、あなたの組織のDNSサーバーへの委任情報を正しく設定していない、あるいは設定ミスがある場合に発生します。
現場でのトラブルシューティング:
「このIPアドレスはうちのサーバーなのに、逆引きできない！」という場合は、まず+traceでどこまで問い合わせが届いているかを確認します。そして、そのIPアドレスブロックを割り当てている上位のプロバイダやレジストリに、ゾーンの委任設定が正しいか問い合わせることになります。泥臭いですが、これがNOCの日常です！
3. ファイアウォールによるブロック（郵便局への道が通行止め）
地味ですが、これもよくある原因の一つです。DNSクエリそのものが、途中のファイアウォールによってブロックされている場合があります。特に、社内ネットワークから外部のDNSサーバーへのUDPポート53の通信が制限されていると、逆引きだけでなく、正引きも含めてDNSの名前解決ができなくなります。
これは、郵便局に行こうとしたら、途中の道が通行止めになっていてたどり着けない、という状況ですね。
確認方法:
ネットワークの疎通確認 (ping や traceroute など) や、ファイアウォールの設定を確認します。
—
逆引きの活用シーン：なぜNOCエンジニアは逆引きにこだわるのか？
「結局、逆引きって何に役立つの？」という疑問、ごもっともです。しかし、実はネットワーク運用監視やセキュリティの現場では、逆引きが非常に重要な役割を担っています。
1. ログ解析とトラブルシューティング:
サーバーやネットワーク機器のログには、通信元のIPアドレスが大量に記録されています。しかし、10.0.0.1 や 203.0.113.50 というIPアドレスだけでは、それが「どのサーバー」からのアクセスなのか、一目で判断できません。
そこで逆引きをすることで、webserver01.example.com や attacker.malicious.net のようにホスト名を特定できれば、問題の切り分けや原因究明が格段に早くなります。
2. セキュリティ対策:
- スパムメール対策: 多くのメールサーバーは、受信したメールの送信元IPアドレスを逆引きし、ホスト名が信頼できるものかを確認します。PTRレコードが設定されていない、または疑わしいホスト名が返されるメールサーバーからのメールは、スパムとしてブロックされることがあります。
- 不正アクセス調査: ログに記録された不審なIPアドレスを逆引きすることで、攻撃元のサーバーや組織を特定する手がかりになることがあります。
- SSH接続のセキュリティ: LinuxのSSHサーバー設定には
UseDNS yesというオプションがあります。これが有効だと、SSH接続を試みるクライアントのIPアドレスを逆引きし、ホスト名を取得します。これにより、~/.ssh/authorized_keysファイルなどでホスト名によるアクセス制御を行うことが可能になります。
3. ネットワークインベントリ管理:
大規模なデータセンターでは、数多くのサーバーやネットワーク機器が存在します。IPアドレス管理台帳とDNSのPTRレコードを連携させることで、IPアドレスからその機器の用途や責任者を素早く特定できるようになります。
—
まとめ：IPアドレスとホスト名の両面からネットワークを理解する
今回は、digコマンドを使ったIPアドレスの「逆引き」と、その裏側にあるPTRレコード、in-addr.arpaドメイン、そして「ゾーン委任」という仕組みについて解説しました。
最初は少し複雑に感じるかもしれませんが、
- 正引き: 名前から住所（ホスト名からIPアドレス）
- 逆引き: 住所から名前（IPアドレスからホスト名）
という基本的な役割と、それぞれがDNSの世界でどのように実現されているか、そしてどんな時に役立つのかを理解していただけたでしょうか。
特に、逆引きができないときの「ゾーン委任の問題」は、現場のNOCエンジニアが粘り強く調査し、関係各所と連携して解決に導く、泥臭いトラブルシューティングの典型例です。
IPアドレスとホスト名、この両面からネットワークを見渡せるようになると、トラブルシューティングの視野がぐっと広がります。
焦らず、一歩ずつ理解を深めていきましょう！また次回の記事でお会いしましょう！
コメント