昨日，「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」というのが出ていたので，慌てて， Netowl と eNom を見に行った。見たのは， Netowl のレジストラロックがしっかりかかっているかと，両方の登録データが変わっていないかだけだが。パスワードは，もともとかなり複雑にして使っているので，変えても仕方ないだろうし。変えるタイミングもあるし。レジストラロックというのは，レジストラが提供しているわけで， Netowl のレジストラロックは Netowl が提供しているわけだ。 com ドメインの場合， Netowl はリセラーでレジストラとしては行動しないようだが，その場合でも，ロックは効くんだと思う。判断理由は， Value-Domain のときも Value-Domain はリセラーでレジストラは Key-Systems だったんだが，そのときも同じシステムだったからだ。それに eNom の設定では， Netowl がリセラーとして管理している私のドメインについては，そういう項目はなかったし。もっとも，確認はとっていないから，私が勝手に推測しているだけだ（汗）。
ところで，「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」で記述のあるロックは，レジストリロックだ。これがよくわからない。記事を書いた時点（11/6）では，脳ミソが勝手に「リ」を「ラ」と読んでいた（滝汗）。レジストリロックというと，レジストリ側でロックをかけるという意味だろう。 com のレジストリというと， InterNIC ですかね。 jp だと， jprs だよな。 jp はともかく com って膨大な数だよ。実際の管理がレジストリ自体で可能なのかね。実は，レジストラやリセラーに管理委託しているとかなるんじゃないのか。
レジストラロックていうのは，多分， clientTransferProhibited の状態のことだと思うんだけど，レジストラロックとレジストリロックってどう違うんですかね。アチコチ読んでもすっきりと納得がいかない。
どなたか，ご指導よろしくお願いいたします m(_”_)m。
この件に関しては，ユーザにできることは限られているから，レジストラや権威 DNS サーバの運営者や CDN サービスなどにしっかりしてもらわないとどうしようもない。今年， eNom に移管するとき，過去の事件が頭をよぎったりしたのだが， jp 国内のドメインでもこういうことの起こる時代になったんだな。狙われるようになったら，国内には危ないところが，いっぱーーいあるんだろうと，戦々恐々である。
「速さにたじろぐ」のときにも書いたが，我が国は結構蚊帳の外だったからねぇ。ありがたくないけど，このあたりもグローバル化の時代を迎えたわけだ。
こんなことなくても，白物家電がゾンビ PC 化したり， USB の設計そのものが悪用されたりと，なんか無力感が甚だしいのになあ。
しかし，関連で名前挙がっている企業がおっきいとこだねえ。大きいとこはピンポイントで狙われるだろうから，その企業が特に弱いということではなく，強度については，どこも変わらんのだろうなあ。
追記(11/7)：
上の追記で，レジストリロックとレジストラロックについて，
> どなたか，ご指導よろしくお願いいたします m(_”_)m。
と書いたのだが，くりくりさんが，「登録情報の誤りによるドメインの停止措置について」というページを教えて下さった。なるほど，これがレジストリロックなんですね。よくわかる。
レジストラロックは，あくまで， Transfer Prohibited ，つまりドメイン移管禁止だもんね。当然ながらユーザが ON/OFF できる（リセラーに頼んで変えてもらうということも含めて）。レジストリロックは，ドメインの期限切れではないのに registrar hold にされることなんだ。ということは，移管どころか，ドメインの使用自体ができなくなってしまうわけだ。対応が遅れるとドメインが削除される可能性もあると。なるほど。
くりくりさん，ありがとうございました m(_”_)m。
「（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」への8件の返信
おはようございます。
whoisの情報が書き換えられたとかいわれてますが
見たのはip変更されてないかどうかくらいです。
ひとつだけ正引きできなかったドメインがあったので
設定しなおしたら名前解決できるようになりました。
なんでできなかったか不思議。
対策はアカウントのパスワード強化くらいです。
たった4文字でしたからね（笑）
12文字に変更。
くりくりさん，こんにちは。
毎度，お疲れさまです。
今回の問題も，一般ユーザへの影響が出そうですね。権威 DNS の乗っ取りとかもそうですが， WHOIS 書き換えられて，全く別のとこに飛ばされても，ドメイン名が同一では，一般ユーザには，打つ手がない気がします。
何にしても，サーバ管理者は，早急に自分のところの情報を確認すべきです。もし，変なことがある場合は，すぐに対処しないといけません。←自戒です。
> ip変更されてないかどうかくらいです。
IP に，知らないいかがわしいものがないか調べるのが，手っ取り早いんでしょう。ドメインが多数ある場合，どうやって一括で調べるのか，分かってませんが（汗）。
なんか，いろいろ，目白押しの年ですねぇ。ドメイン乗っ取りは，昔も聞きましたが，手法は変わっているのでしょうか。 jprs の勧告ではその辺はわかりませんね。
ところで，本記事に追加しましたが，「レジストリロック」と「レジストラロック」の違いがすっきりと納得いきません。どこかにいい説明はないですか。
こんにちは
＞ドメインが多数ある場合，どうやって一括で調べるのか
ちゃんと目で確かめないといけませんから、
ブラウザで確認です。
面倒だから次はスクリプトでこんな風にしようかなと・・・。
#!/bin/sh
for i in superweibu.com google.com
do
dig $i >> ip.txt
done
＞「レジストリロック」と「レジストラロック」の違い
見てみましたが、いいサイトありませんね。
あんまり一般的ではないのかもしれません。
普通は
レジストラロック（ドメインロック)
は移管できないようにロックする方法です。
レジストリロックはドメイン停止ですね。
whoisで情報がわかるみたいです。
http://domain.plusblue.net/jp/faq/02021860/index.php
jpcertにレジストリロックがかいてありましたけど、
検索してでてこないところをみると一般的ではないし
簡単にできなさそうですね。
くりくりさん，こんにちは。
早速ありがとうございました。本記事に追記しました。
> jpcertにレジストリロックがかいてありましたけど、
期限切れでないのに，「Status: REGISTRAR-HOLD」となるという話ですから，これはやはり，レジストリにしかできない話ですね。
これだけはっきり違うことがなんで頭の中でこんがらがってしまったのかを考えたのですが，どうも「ドメインロック」という通常使う用語が理由のような気がします。ドメイン停止と訳せないこともない言葉なので，この辺でごちゃごちゃになったようです。
#!/bin/shfor i in superweibu.com google.comdodig $i >> ip.txtdoneなるほど。
superweibu.com google.comのとこが 100 もあったら，これも txt かなんかで与えるんですか。今晩は
/var/www/vhost/にFQDNでディレクトリつくってるんで、
それからlsかなんで抽出して変数iにぶっこんでgrepでip.txtからひっかけて見やすくしようかなとおもいましたけど（ｗ
やっぱり、確実なブラウザのチェックですかね（笑）
2時間半かかりましたけど・・・・。
whoisの情報に使えないメアドが登録してあって、
いきなりドメインの停止(iccan規約違反)をくらったことがあります。
最初原因がわからなくて、権限委譲にトラブルがあるときがついたら夜中の2時になってましてね。
バリュードメインに質問したんですが、受付部門じゃ対応とれなくてその上のサポートチームが出てきてやっと解決です。
これが今思うとレジストリロックだったのかな？
くりくりさん，こんばんは。
> /var/www/vhost/にFQDNでディレクトリ ～～ おもいましたけど（ｗ
なるほど。
> やっぱり、確実なブラウザのチェックですかね（笑）
確実でしょうけどねぇ。お疲れさまでした。
> これが今思うとレジストリロックだったのかな？
ですね。「使えないメアドが登録」っていうのは条件にドンピシャリですもんね。しかし，今回の悪意の書き換えの場合は，「使えないメアドを登録」なんかしないでしょうから，サイト運営者が確かめて訴えないと，なかなかわからない気がします。レジストリが，過去のデータとのクロスチェックをしてくれるんだと，可能かもしれませんが。
こんにちは
plesk11でsslv3無効化しましたけど、製作は特に何もいってきませんでした。
俺はie6くらいしか影響考えなかったんですが、jraをみるとie8も影響うけたんですね。
さて、poodleの脆弱性がみつかってtlsに移行したサイトもそれほど多くないみたいです。
もっと移行したかとおもいました・・・。
http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html
上記の結果からサーバーはsslをサポートしながら
先にブラウザのほうからサポートしなくなってsslは消えていくかなと思います。
おまけでサーバー側各アプリのssl無効化とtlsかをしていますが、dovecotだけバージョンの関係でリビルドしないといけません。
https://www.linode.com/docs/security/security-patches/disabling-sslv3-for-poodle
くりくりさん，こんばんは。
> jraをみるとie8も影響うけたんですね。
IE8/9 でも，デフォルトで， TLS にはチェックが入ってないということなんでしょうか。
BEAST が発表されたときに，実際にはそういうシチュエーションて多くないからそんなに怖くないよって話だったのですが， POODLE with BEAST となると，ワッハッハ。カミンスキー氏とハーブリッ嬢のデートみたいなもんじゃないですか。シャレになりません（爆）。
> 先にブラウザのほうからサポートしなくなってsslは消えていくかなと思います。
素早いですから，そうなるでしょう。
問題は，ユーザがどうするかですね。全くそういう意識のない人もいますから。こんな記事を読んだのですが，中に「パソコンのソフトの更新をしていなかったりパスワードの管理がずさんだったりしたことを理由に『補償額を減額したケースがある』」という記述があります。こういうことが起こりうるということがわかれば少し意識も変わるかもしれないと思うのですが……興味がないとこの手の記事さえも目にかかりませんからねぇ。
> dovecotだけバージョンの関係でリビルドしないといけません。
お疲れさまです。現時点だと， CentOS6.6 は dovecot 2.0.9 ですか。 CentOS7 だと 2.2 系になっているようですね。