2018年06月23日に初出の投稿

Last modified: 2018-06-23

特定のサイトやサーバへの応答開始が30秒くらい遅延する問題は、取引先と幾つか検証してみて、当社のルータ(default gateway)が逆引きできないせいではないかという仮説が出ている。実際、SAKURA のサーバに ssh でアクセスしたときのハンドシェイクに時間がかかる問題は UseDNS = no を設定して解決したから、一理ある。

そういうわけで、昨日はネットワークの機器の作業をしていたのだが、RTX 3000 は最初から静的な DNS レコードなど設定してはいないし、そもそもキャッシュポイゾニング攻撃の恐れがあるため、外部からのリクエストに応答する設定になど簡単にはできない。今年の3月から、一斉に色々なサイトで逆引きに応じるかどうか検証するようなフローでサイトやサーバへのリクエストを処理するような仕様が流行し始めたのか? そんなことはなかろう。

それに、ひとくちに「逆引き」と言っても、ルータ自身にホスト名を設定して応答することなのか、それともネームサーバに PTR レコードを設定することなのかで意味が違ってくる。前者はただの「オレオレ名前解決」なので信頼などできない。こんなレスポンスがあるかどうかを判定するために、自身のレスポンスを遅延させるサーバなど、ただのセキュリティ劇場で演じているだけの三文役者だ。

しかし、困ったことに当社のドメインを登録しているムームードメインやお名前.com の DNS サービスは、PTR レコードの登録を受け付けていない。したがって、PTR を登録するには別の(もちろん PTR レコードを設定できる)ネームサーバを借りるしかないのだが、CloudFlare のような無料の DNS サーバだと、PTR レコードは確かに登録できるのだが、FQDN を nslookup すると A レコードの IP アドレスではなく、CloudFlare の IP アドレスが返ってくるという変なことになる。もちろん、これはこれで CDN としての振る舞いなのだろうが、純粋な DNS の挙動ではなく、期待するようなレスポンスとは言えない。なんだかんだ言っても、自分で Bind を建てるのがよさそうな気がするな。SAKURA の専用サーバに一つ建てようかな。

ちなみに、当社はプロバイダ(USEN、現在はアルテリアネットワークス)との契約時に DNS の設定はしていない筈だし、3月にコーポレートのウェブサーバを変更しただけでプロバイダの DNS サーバの設定が連動して変わることなどありえないわけだが、プロバイダにも確認してくれと言われている。

いや、それ以前に来週は ISMS の監査があって東京にも出張するし、それ以外にも家族の事情があって、とりあえず遅延しているにすぎないネットワークなど、30秒くらい待ってろと言いたいが。何度も言うが、当社はアメリカ国防総省ではない。相手が電通だろうと NHK だろうと、メールの返信が 30 秒くらい遅れただけで国家的な危機が訪れるわけでもあるまい。どのみち理知的なビジネスプロセスなど最初から構築してもいない連中が、なにをウェブの広告ごとき瑣末な(市場規模はともかく人が生存するために必須でもなんでもない)産業で形式ばったことを言っているのか。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook