QRコード
多数派は言わざるですので
引用:窒息死亡事故が多発する餅はなぜ規制されないのか？
危ないと言われれば、コストがかかり多少利便性が悪くなっても、危なくないように対応するのが日本の行政だ。彼らは国民の声を聞いて仕事をしているのだ（と少なくとも彼らは主張するだろう）。
責任の一端は彼らにそういう仕事をさせてきた我々社会の側にもある。無視できるほどのリスクに目くじらを立て、責任者は誰だ？と犯人探しをし、多額の損害賠償と再発防止策を求める。そのたびに新たな規制が追加され、少しずつ社会は住みにくくなる。もちろんそうした規制の中には必要なものも多い。しかし不要なものも多いのもまた事実だ。
この負の連鎖をなんとか断ち切り、より全体的な視点でバランスのとれた対応をすることは出来ないのか、それこそ政治主導の出番なのだろうけれど……ねえ？
恐らく、無視できるほどのリスクに関しては、犯人探しをしたり多額の損害賠償を求めたり再発防止策を求めている方々は少数なはずで、それらを不要と思っている人は多数なはずだと思うのですが、そもそも不要と思っている人は目くじらを立てない、つまり、意見を出さないですから。
何も言わない人と何か言ってくる人のどちらに対応するかといえば、通常、何か言ってくる人に対応せざるを得ないでしょうし。「危ないと＊言われれば＊」もそうなのでしょう。
そういう多数派が積極的に意見を出さないという意味で「責任の一端は彼らにそういう仕事をさせてきた我々社会の側にもある」というのは的を射ているとは思いますけど、例えば、モンペにその他の親御さんが「おまえの教育は間違っている」と思っても面と向かって主張しないのと同じで、ある意味三猿的なものが今の日本の文化的なところに根付いてますから。
結局のところ、より全体的な視点でバランスのとれた対応をするためには、そういう物言わぬ少数派が積極的に意見を言う社会を作るか、行政が積極的に意見を取りに行くかしかないんでしょうけど、それをどう実現するかが難しいところですかね。
なんだかな…ServersMan@VPS
今朝、ServersMan@VPSのメンテに関してメールが。
勝手に環境弄っておいてその修正は客の方で行えと？まあ、各所で勝手に弄るなと突っ込まれた手前、弄れない立場になってしまったんでしょうかね。個人的には、どのみち使ってないし使わない機能なのでどうでもいいんですが。そもそも、
と言っておきながら、その対策を客に任せていないからこういうことになるんじゃないかと思ったり。まあ、途中から高負荷対策などという名目が案内メールに入り込んできてますので、DTI都合の意味合いが大きいメンテなんだと邪推したりしてますが。
別にたいした料金払っているわけではないので、弄りたきゃ弄ってもらえればいいとは思うのですが(*1)、なんかセキュリティ対策を口実に負荷対策を行うのはなんだかなといったところ。言っていることが首尾一貫してないし、言い訳がましい口実を書いているように読めてしまうところが個人的に反感を買う要因ではないかと思うところ。
*1: 事前に断る必要はあると思いますけど。
引用:ServersMan@VPS メンテナンス経緯のご報告 ならびに AirDisplay設定変更のお願い
# 当メールは、SSH のポート番号変更にあたりまして、再度手動による設定が
# 必要なお客様を対象にお送りさせていただいております。
# 大変ご面倒ながら、ご協力をお願いいたします。
勝手に環境弄っておいてその修正は客の方で行えと？まあ、各所で勝手に弄るなと突っ込まれた手前、弄れない立場になってしまったんでしょうかね。個人的には、どのみち使ってないし使わない機能なのでどうでもいいんですが。そもそも、
引用:ServersMan@VPSサービス SSH接続用のポート変更に伴う設定変更のお願い
プリインストールされているアプリケーションの他、お客様が自由に環境を構築できるメリットもありますが、その反面、セキュリティ対策もお客様ご自身で行っていただく必要があります。
と言っておきながら、その対策を客に任せていないからこういうことになるんじゃないかと思ったり。まあ、途中から高負荷対策などという名目が案内メールに入り込んできてますので、DTI都合の意味合いが大きいメンテなんだと邪推したりしてますが。
別にたいした料金払っているわけではないので、弄りたきゃ弄ってもらえればいいとは思うのですが(*1)、なんかセキュリティ対策を口実に負荷対策を行うのはなんだかなといったところ。言っていることが首尾一貫してないし、言い訳がましい口実を書いているように読めてしまうところが個人的に反感を買う要因ではないかと思うところ。
*1: 事前に断る必要はあると思いますけど。
続・YAMAHAルータDNSリカーシブサーバー機能検証(フルリゾルバがBIND 9.7.2-P3の場合)
YAMAHAルータDNSリカーシブサーバー機能検証
同じテストをフルリゾルバをBIND 9.7.2-P3にしてやってみた。
まず、
となる場合。結果は、
42/43 tests passed(failedしたのはEのみ)。かなり良好です。
次に、
となる場合。ルータのみに問い合わせる場合です。結果は、
6/43 tests passed(passしたのはB, G.1, G.2, G.3, G.4, G.5)。変わらず悲惨です。
次に、
となる場合で、直接フルリゾルバに問い合わせる場合です。結果は、
43/43 tests passed。この上ないですな。Unboundの場合はバージョンが古いからか設定に不足があるのかもですね。いずれにしろ、RTX1100のDNSリカーシブサーバー機能は駄目っぽい。
同じテストをフルリゾルバをBIND 9.7.2-P3にしてやってみた。
まず、
dhcp scope optionを付けない場合。要するに、DNS Servers . . . . . . . . . . . : 192.168.141.1
192.0.2.81
となる場合。結果は、
42/43 tests passed(failedしたのはEのみ)。かなり良好です。
次に、
dhcp scope option 1 dns=192.168.141.1とした場合。要するに、DNS Servers . . . . . . . . . . . : 192.168.141.1
となる場合。ルータのみに問い合わせる場合です。結果は、
6/43 tests passed(passしたのはB, G.1, G.2, G.3, G.4, G.5)。変わらず悲惨です。
次に、
dhcp scope option 1 dns=192.0.2.81とした場合。要するに、DNS Servers . . . . . . . . . . . : 192.0.2.81
となる場合で、直接フルリゾルバに問い合わせる場合です。結果は、
43/43 tests passed。この上ないですな。Unboundの場合はバージョンが古いからか設定に不足があるのかもですね。いずれにしろ、RTX1100のDNSリカーシブサーバー機能は駄目っぽい。
YAMAHAルータDNSリカーシブサーバー機能検証
RTX1100のDNSリカーシブサーバー機能ですがDNSSECが絡むとあまりよろしくない感じがするので検証してみようかと。検証といってもhttp://www.nic.cz/dnssectests/あたりからダウンロードしたDNSSEC Hardware Tester(Windows version)によるものなのでおもいっきり他力本願ではありますが。
まあ、枯れた機種かもしれませんけど、一応現役で売ってますし、ファームウェアも2010年12月30日現在最新のRev.8.03.90にして検証してみました。
RTX1100のプライベート側のIPアドレスは192.168.141.1、DNSサーバーのIPアドレスは実際のものを書くのも何なので192.0.2.81としておきます。192.0.2.81で動作しているフルリゾルバはFedora EPELのunbound 1.4.4です。この場合、要所だけ書くと、
みたいな設定を入れるかと思うんですが、この設定でWindowsクライアントなんぞで
DNS Servers欄にDNSリカーシブサーバー機能が動作しているRTX1100のIPアドレスと実際のDNSサーバーのIPアドレスが返ってきます。実際、この場合はそこそこ良好な結果(38/43 tests passedでfailedはC.1, C.2, D.1, D.2, Eのみ)を叩き出すのですが、なんとなく192.0.2.81に直接問い合わせた結果がよいだけで本来のDNSリカーシブサーバー機能は頑張ってないんじゃないのかと思えたので検証してみる次第。
そのようなわけで、DHCPがDNSサーバーとして192.168.141.1しか返さないように、以下の設定を加えます。
これで、
となります。これでテストしてみると、
6/43 tests passed(passしたのはB, G.1, G.2, G.3, G.4, G.5)のみ。結構悲惨な有様。
そもそもルータにDNSリカーシブサーバー機能が要るのかどうかは兎も角、RTX1100のDNSリカーシブサーバー機能は使えない感じ。何か設定が足らんのでしょうか。最新の機種だとそうでもないんですかね。
ちなみに、実際のルータの全設定は以下のような感じです。なるべく余計なものは書かないようにしたつもり。
まあ、枯れた機種かもしれませんけど、一応現役で売ってますし、ファームウェアも2010年12月30日現在最新のRev.8.03.90にして検証してみました。
RTX1100のプライベート側のIPアドレスは192.168.141.1、DNSサーバーのIPアドレスは実際のものを書くのも何なので192.0.2.81としておきます。192.0.2.81で動作しているフルリゾルバはFedora EPELのunbound 1.4.4です。この場合、要所だけ書くと、
…
ip lan1 address 192.168.141.1/24
…
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.141.192-192.168.141.224/24 expire 1:00
dns service recursive
dns server 192.0.2.81
…
みたいな設定を入れるかと思うんですが、この設定でWindowsクライアントなんぞで
ipconfig /allなんぞを実行すると、以下のような感じで、IP Address. . . . . . . . . . . . : 192.168.141.192
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.141.1
DHCP Server . . . . . . . . . . . : 192.168.141.1
DNS Servers . . . . . . . . . . . : 192.168.141.1
192.0.2.81
Lease Obtained. . . . . . . . . . : 2010年12月30日 0:42:09
Lease Expires . . . . . . . . . . : 2010年12月30日 1:42:09DNS Servers欄にDNSリカーシブサーバー機能が動作しているRTX1100のIPアドレスと実際のDNSサーバーのIPアドレスが返ってきます。実際、この場合はそこそこ良好な結果(38/43 tests passedでfailedはC.1, C.2, D.1, D.2, Eのみ)を叩き出すのですが、なんとなく192.0.2.81に直接問い合わせた結果がよいだけで本来のDNSリカーシブサーバー機能は頑張ってないんじゃないのかと思えたので検証してみる次第。
そのようなわけで、DHCPがDNSサーバーとして192.168.141.1しか返さないように、以下の設定を加えます。
dhcp scope option 1 dns=192.168.141.1
これで、
ipconfig /allなんぞを実行すると、IP Address. . . . . . . . . . . . : 192.168.141.192
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.141.1
DHCP Server . . . . . . . . . . . : 192.168.141.1
DNS Servers . . . . . . . . . . . : 192.168.141.1
Lease Obtained. . . . . . . . . . : 2010年12月30日 0:52:36
Lease Expires . . . . . . . . . . : 2010年12月30日 1:52:36
となります。これでテストしてみると、
6/43 tests passed(passしたのはB, G.1, G.2, G.3, G.4, G.5)のみ。結構悲惨な有様。
そもそもルータにDNSリカーシブサーバー機能が要るのかどうかは兎も角、RTX1100のDNSリカーシブサーバー機能は使えない感じ。何か設定が足らんのでしょうか。最新の機種だとそうでもないんですかね。
ちなみに、実際のルータの全設定は以下のような感じです。なるべく余計なものは書かないようにしたつもり。
dhcp scope option付
dhcp scope option無
