Scribble at 2026-07-23 12:36:22 Last modified: 2026-07-23 12:46:29

８年くらい前の話になるが、「さくらのクラウド」に構築した小さいインスタンスに nsd を入れて、弊社の専用ネーム・サーバを運用していたことがある。これは、詳細な記録を残してあるトラブルシューティングの一環で実施したことだった。本社の事業所が新しいテナント・ビルへ移転してから、どういうわけか特定のサイトへアクセスしたときだけ非常にレスポンスが重くなったり、酷いときはタイムアウトするようになった。サイトの種類は上場企業のコーポレート・サイトから個人のブログまで色々だったから、どういうサイトやサーバなどへアクセスしたときに起きるのか、要因や条件を特定するのに半年くらいかかってしまった。そうしているあいだに、社内で運用している RTX3500 というヤマハのルータに ISP である USEN から割り当てられた固定 IP アドレスだけでなく、逆引きの設定も必要なのではないかという疑いが生じた。最初は、これは除外していたのだが（なぜなら、もし逆引きが必要なら、移転するまで他のテント・ビルでも同じルータを使っていたのに、その頃は問題がなかったからだ。テナント・ビルの違いでルータの挙動やリモート・サーバ側の挙動が変わるなんておかしい）、異なるテナント・ビルで何らかの通信条件が変わった可能性はあるし、USEN の契約も 1 Gbps の契約に変更したため、そのときに何か通信条件が内部的に変わった可能性があるからだ。ISP から割り当てられる固定 IP アドレス（グローバル IP アドレス）は、インターネットの通信ネットワークの出口であるルータ機器（RTX3500）の外側（つまり WAN 側）を向くインターフェースに対して割り当てられる（内側の IP マスカレードなどの説明は、ひとまず省く）。

しかし、一般論として言えば、社内から社外にアクセスする状況でルータ機器に割り当てられた IP アドレスの逆引きを設定しないと外部サイトのレスポンスが遅くなるなんてことは、ない。寧ろ、逆引きの処理なんてものを追加する方が例外的であり、しかもその影響はリクエストするクライアント側よりもレスポンスするリモート・サーバ側の方で深刻なものとなりやすい。僕も20年くらい前に駆け出しのサーバ・エンジニアだった頃に、Apache の httpd.conf で逆引きの設定（HostnameLookups）を有効にしてしまい、ウェブ・サーバ（つまりはサイト）を落としたことがある（笑）。それくらい、逆引きはサーバに負荷がかかるのだ。ちなみに、HostnameLookups はリクエスト（アクセス）してきた相手の IP アドレスからホスト名を逆引きする機能であり、ログ・ファイルに IP アドレスではなくホスト名を記録する。しかし、そのためだけにウェブ・サーバには逆引きを解決するコストがかかる。もちろん、画像１個や CSS ファイル１個のアクセスに対しても DNS の問い合わせがウェブ・サーバの側で発生するため、その負荷は非常に大きい。一部の上場企業など、強力なマシンや太い帯域の回線を専有で運用しているならともかく、一般的な中小企業がデータ・センターでホスティングやハウジングで運用しているていどのウェブ・サーバでやるようなことではない（よほどリクエストの内容が特定の相手からだけ限られていて少ないなら別だが）。

しかし、特にアクセスが遅くなるサイトに上場企業や巨大企業のコーポレート・サイトが多かったという状況だったので、可能性としては相手が逆引きを行っていて、ちゃんとホスト名がルータ機器に割り当てられていないと名前の解決ができないうちはレスポンスを返さないという挙動で遅延が起きている可能性がゼロとは言い切れないと考えたわけである。

そこで、「さくらのクラウド」に建てたインスタンスへ nsd を導入し、ISP から権威ネーム・サーバの権限を委譲してもらって、ルータへの逆引きリクエストに対する権威ネーム・サーバとして運用することにしたわけである。そもそも、実際にこういう機会に調べてみると、実は逆引きの権威ネーム・サーバは権限が委譲されていたのだけれど、その権威ネーム・サーバが既に存在しなかったり、あるいは15年くらい前に弊社で採用していた派遣のネットワーク・エンジニアが使っていた xname.org という無料のネーム・サーバだったりしたのだった。なんでそういう杜撰な状況に気づかなかったかというと、逆引きの問い合わせへ応答するために使うことにしたドメイン（.org ドメイン）は、弊社の社名という理由で取得しただけで使っていなかったからだ。しかし、別の用途では逆引きのレスポンス用に使ったらしい。ともあれ、このようにして逆引きの解決を正常にしたところ、特定サイトへのアクセスやメールの送信エラーも解消されたわけである。ここに至るまでは、社内で起きていた問題なので、Wireshark なども使って社内のネットワーク機器（特にインテリジェント・スイッチ）に問題があるのかもしれないとか、色々とやったのだが、まさかいまどき逆引きが必要とは思わなかった。

そういうわけで、８年くらい前には nsd のお世話になったこともあったけれど、いまの所在地である WeWork へ移転するよりも前の事業所へ移った頃には逆引きの有無にかかわらず通信が正常に行えるようになったので（これもよく理由がわからないのだが）、nsd は一時的に使っただけである。だが、このようなツールの運用はホビーとしても楽しいし、色々と他に調べてみると、上にご紹介したように日本のユーザ会もあって運営されているようだ。そして、nsd を導入した頃は権威ネーム・サーバだけが目当てだったから着目していなかったけれど、同じく NLnet Labs がリリースしている Unbound には、また別の用途がありそうだ。それは・・・hosts ファイルの代わりにしてみるということである。

hosts ファイルも、Windows では古くから仕込まれている機能であり、DNS Client (dnscache) が扱う古典的な名前解決の仕組みだ。もちろん、ローカル・コンピュータ内部でのオリジナルな名前解決を定義するだけなら hosts ファイルを扱っていればいい。わざわざ Unbound を入れてまで別の、しかも更に複雑な設定で名前を解決する必要はないだろう。たとえば、僕はインスタグラムのコンテンツが見られない（ようにしている）。それは、hosts ファイルに、

0.0.0.0 instagram.com

などと記述してあるからだ。これだけではなく、多くのアド・ネットワークやマーケティング・サービスや不正なアクセス元のホスト名など、なんだかんだと 2 MB くらいの分量になっている。約80,000行だ。それでも特に問題なく過ごせているし、ウェブサイトへのアクセスに支障があったり遅延が生じることもない。なので、ホビーとして Unbound（Windows 版のバイナリもある）を導入してみるのはいいが、マシンのパフォーマンスにどれくらい影響があるのか分からないのは不安がある。ただ、その不安が杞憂なのかどうかを試してみるのもいいのだろう。たとえば、Unbound を使う場合と hosts ファイルを使う場合とで、127.0.0.1 の httpd に設定してある適当な FQDN のサイトへスクリプトか apache bench で大量のアクセスを送ってみて、それぞれの条件でのパフォーマンスを比べてみるというのも面白い（自分のマシンの中で完結するから、自分で自分自身を DoS 攻撃したと非難するような人はいまい）。