Scribble at 2021-04-01 12:44:41 Last modified: unmodified

ベアメタルの筐体で借りている専有のサーバをクラウドのインスタンスへ移行している。ほぼ全ての現行ステージング環境やテスト環境を移行したので、残りは NSD を動かしている逆引きの権限委譲を USEN ICT Solutions に設定変更してもらうという作業がある。これは事情を説明すると長くなるが、要するに当社の事業所のルータに設定しているグローバルの IP アドレスにドメインが紐付いているため、その逆引きが解決できないとアクセスが非常に重くなるサイトがあるからだ。

それにしても、いちいち逆引きの解決結果をみてアクセスを許可しているサイトがあることにも驚く。ふつうはウェブサーバに著しい負荷がかかるため、バランサの背後によほどの処理能力のクラスタを組んでいない限りは、サイトが落ちる。Apache で HostNameLookup しているのと同じだからだ。よく、アクセス解析の素人がアクセス元について IP アドレスでは分からないのでホスト名にしてほしいなどと、どこからか仕入れてきた知識で要求したりするものなのだが、こういうことは Splunk のようなログ解析サービスでやるべきことであって、ウェブサーバでログを保存する際にオンデマンドで IP アドレスからホスト名へ逆引きするのは、おおむね愚行である。

とは言え、実際に逆引き（できないとタイムアウトすることも多い）の結果でアクセスの可否を判定しているサイトがあるのだし、対応しなければいけない。たいていの個人のネット環境だとゲートウェイに紐付いているホスト名は ISP が解決の権限をもってくれているし、そもそもダイナミック DNS であることが多いため、解決結果など固定されていないものだから、家庭の側ではどうにもしようがない。でも、その代わりに、サイトで逆引きの結果を見ていようとアクセスするのに問題はないというわけである。たとえば、日立製作所のサイト（www.hitachi.co.jp）は逆引きをしているのだが、大抵の家庭からのアクセスでは何の問題もない筈だ。

というわけで逆引きの権限を委譲してもらって、自力でネームサーバを構築・運用するのが適切という環境もあるわけで、当社ではこれをやってアクセスが安定したのである。とは言え、ネームサーバとは言っても BIND のようなバグだらけで鈍重な「ガラクタ」を導入して放置するのは危険な気がする。そこで、機能を最低限に絞って NSD の逆引きサーバを建てるのがよいという結論に至って、2017年の11月から運用を続けてきた次第である。NSD は扱いがシンプルで動作も軽いし、必要最低限のことだけに挙動を制約できるため、余計なことをさせたまま攻撃に晒される心配がない。