Chromeで.devのドメインがHTTPだと見られない件の解説
本件、あちこちで悲鳴が上がってたけど、色々調べたら面白かったので解説。
元々はgTLDは.comとか.netとかの22種類しかなかったので、各社が組織内のネットワーク（開発環境とか）でオレオレTLDとして勝手に.devを使ってた。
でもgTLDがわんさか増えて、とうとう.devというTLDもできてしまい、色んなところで「やばい名前衝突(Name Collision)するわ・・・」という話題が出たのが2014年ごろ。
ちなみにICANNWikiによると、この.devは元々AmazonとGoogleで「俺がレジストリになる！」と奪い合ってたけど、youとtalkをAmazonに譲って、代わりにdevをGoogleがゲット、みたいな経緯があった模様。
レジストリってのはあれな、そのTLDの唯一の卸元というか、生産元みたいなもの。だからあちこちで「Googleが.devを買った」って言ってるのは、この「Googleが.devのレジストリになったこと」を指してるんだと思う。
んで今回Googleが「Chromeで.devを開くと強制的にHTTPSにリダイレクトされる」という暴挙に出たのは「Googleは2014年にdevのレジストリ（生産元）になった。でもまだ.devのドメインは一般発売していない。ってことは今.dev使ってるやつは、全部買わずに勝手に使ってるやつなので何してもいいよね。強制リダイレクトさせるわ」っていう考えなのかなと推測してる。
.devだけじゃなくて.appもみたいだし、このドメインがもうHTTPSでしか使えないってことは、Googleは.devを普通に売るんじゃなくて、何か特別な用途で使わせるつもりなのかなー？
で「.devが使えなくなったからとりあえず.testにした！解決！」みたいなのも見るんだけど、なんで.testにしたらいいのか？.testでいいなら.dev2とかでもいいのか？という疑問は浮かばないでしょうか？浮かびますよね？きっと。
ざっくり言うと、.testはいいけど.dev2はだめです。
社内ネットワークにしろ、テスト用のメアドにしろ、「例示として使っていいドメイン」や「テストとして使っていいドメイン」はRFCで定められているので、基本的にはそれを使いましょう。
自分が買ってない＝持ってないドメインを勝手に使うのは、今回みたいなトラブルの元なので控えた方がいいよ、という話でした。
sudoとsuで聞かれるパスワードは違う
sudoは「他のユーザとしてコマンドを実行する」ためのコマンド、 suは「他のユーザになる」ためのコマンド。
sudoのとき聞かれるのは、「自分（今のユーザ）のパスワード」で、 suのとき聞かれるのは、「なろうとしている他のユーザ」のパスワード。
たとえば、mochikoユーザでログインして、 sudo cat /root/.ssh/authorized_keys を叩こうとしたら、mochikoユーザのパスワードを聞かれるし、 su - でrootになろうとしたら、rootのパスワードを聞かれる。
今となっては当たり前なんだけど、分かるまでは結構混乱するよね。
ネガティブキャッシュのキャッシュ残り時間が知りたい
DNSキャッシュサーバにネガティブキャッシュ（status:NXDOMAINなどのときの「そんなリソースレコードは存在しない」という情報のキャッシュのこと）が残ってしまって、あとどれだけ待ったらネガティブキャッシュが消えるのか知りたい。
そんなときは、digでキャッシュの残り時間を確認できる。
- 存在しないhogehoge.yahoo.com を引いてみる
SOAレコードで設定されている値から、ネガティブキャッシュのTTLが600秒であることが分かる。
$ dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21575 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 164 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:02:54 2016 ;; MSG SIZE rcvd: 97
- 再度、hogehoge.yahoo.com を引いてみる
ネガティブキャッシュの残り時間が380秒であることが分かる
$ dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36019 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 380 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 11 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:06:34 2016 ;; MSG SIZE rcvd: 97
- 380秒も待てない！ネガティブキャッシュ消したい！というときはrndc flushでDNSキャッシュサーバのキャッシュを消す
# rndc flush
- 再度、hogehoge.yahoo.com を引いてみる
ネガティブキャッシュが消えて、問い合わせに行き、そして再びネガティブキャッシュのTTLが600秒になっている。
# dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30397 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 418 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:09:29 2016 ;; MSG SIZE rcvd: 97
これでやきもき待たなくて済むー。
MXレコードやTXTレコードでは*（アスタリスク）は使えない？
hoge.infra.xyzでもfuga.infra.xyzでもメールを受信できるように、BINDのinfra.xyz.zoneでこんな設定を書いてみた。
mx1 IN A 153.126.198.20 * IN MX 10 mx1.infra.xyz. * IN TXT "v=spf1 a:mx1.infra.xyz -all"
named-checkzoneでエラーはでない、よしよし、とnamedをrestartして、digで
dig hoge.infra.xyz mx dig hoge.infra.xyz txt
を叩いてみたら、なんと何も出ない。 statusはNOERRORなのに、ANSWERは0・・・MXとかTXTだと*（アスタリスク）でワイルドカードの指定はできないのかな？と思ったら、ワイルドカードは「個別の設定があればそちらが優先、なければワイルドカードが適用される」ということらしく、そもそも個別の設定が1つもないとワイルドカードも適用されない模様。
つまり、以下のようにワイルドカードしかない状態だと、hoge.infra.xyzのAを引いても、MXを引いても、TXTを引いても、ANSWERは0なんだけど、
* IN A 153.126.198.20 * IN MX 10 mx1.infra.xyz. * IN TXT "v=spf1 a:mx1.infra.xyz -all"
以下のように、hoge.infra.xyzという個別の設定をした上で、ワイルドカードの設定をした状態で、fuga.infra.xyzを引くと、AもMXもTXTもちゃんと値が返ってきた。
hoge IN A 153.126.198.20 * IN A 153.126.198.20 hoge IN MX 10 mx1.infra.xyz. * IN MX 10 mx1.infra.xyz. hoge IN TXT "v=spf1 a:mx1.infra.xyz -all" * IN TXT "v=spf1 a:mx1.infra.xyz -all"
というわけで、AレコードやMXレコードやTXTレコードでは*（アスタリスク）は使える。 但し、同じ種類のレコードにおいて個別の設定が1つもないと、ワイルドカードも適用されない模様。
という一旦の理解。BINDのDOCUMENTATIONとかちゃんと読めば、説明見つかるかな。
Apache2.2系で中間証明書ファイルを指定するのはSSLCertificateChainFile？SSLCACertificateFile？
Apache2.2系で、SSLサーバ証明書を設置する際に、中間証明書ファイルを指定するディレクティブがSSLCertificateChainFileか、SSLCACertificateFileか、分からなくなってしまったのでメモ。
結論から言うと、SSLCertificateChainFileディレクティブを使うのが正しい。けど、どっち使ってもちゃんとSSLの設定は出来る。
mod_sslの公式ドキュメント（http://httpd.apache.org/docs/2.2/mod/mod_ssl.html）でDescriptionを見ると、
SSLCertificateChainFileディレクティブ：File of PEM-encoded Server CA Certificates SSLCACertificateFileディレクティブ：File of concatenated PEM-encoded CA Certificates for Client Auth
ということなので、同じ「中間証明書を指定する」ディレクティブでも、SSLCertificateChainFileは「SSLサーバ証明書」の中間証明書、SSLCACertificateFileは「SSLクライアント証明書」の中間証明書を指定するディレクティブな模様。
はーすっきり。
でもSSLCertificateChainFileディレクティブを使うのは、「Apache＋mod_ssl」（Apacheにmod_sslモジュールを追加してSSLを使う）のケースだと正解！なんだけど、「Apache＋Apache-SSL」（ApacheにApache-SSLのパッチを当ててSSLを使う）のケースだと、逆にSSLCACertificateFileディレクティブを使うのが正解っぽい。
Apache-SSLってなんですか・・・2009年のリリースが最後だし、もうほぼ使われてないと思っていいのかな・・・。
SSL証明書をSHA-2に変更するときの案内ページまとめ
SHA-1のSSL証明書を発行できる期間もあと半年を切り、SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) によると、割合としては既にSHA-1が40%、SHA-2が60%と、SHA-2の方が多くなってきた模様。
非対応になる端末も把握し、さあいよいよSHA-2に変更するぞー！というときに、さてエンドユーザにどう告知したものか・・・と迷うところも多そうなので、参考になりそうな各社のサイトをまとめてみた。
- 楽天銀行ウェブサイト／インターネットバンキングの証明書「SHA-2」方式への変更について | 2015年 | お知らせ | 楽天銀行
- Tサイト［Tポイント/Tカード］ SHA-2のSSL証明書への移行について
- ガラケーなど一部端末での閲覧終了について（ハッシュ関数「SHA-2」対応）｜エコめがね
- 【再掲】サーバー証明書の更新により一部コンテンツがご利用いただけなくなるPC・スマホ環境について 安藤証券
- よくあるご質問 リクルートの適性検査SPI お知らせ
- カブドットコム証券(ネット証券会社) サーバ証明書更新に伴うPC、携帯端末の動作確認のお願い
- ネットストアで使用している暗号化アルゴリズム変更のお知らせ | お知らせ | 無印良品
- ホットペッパービューティー ハッシュアルゴリズム「SHA-1」から「SHA-2」への移行について
丁寧に説明しているところもあれば、さらっと流しているところもあり、各社さまざま。
しかし上のリストの中にも1つだけあるけど、案内ページをHTTPSでしか見られないのはよくないと思うのですよ。「ガラケーで開いたら見られない！なんで！」って人が、理由を書いてあるページに辿りつけないって、誰のための案内ページなのかと・・・。
イオンシネマ、リニューアル前のドメインをドロップキャッチされるの巻
イオンシネマ（http://www.aeoncinema.com/）のトップページに、こんなお知らせが出てた。
【重要なお知らせ（ご注意）】 当社HPへアクセスされる場合、旧ドメインはご利用にならないようご注意ください。
どうやら2013年7月にワーナーマイカルシネマズがイオンシネマに統合された後、旧ドメイン（warnermycal.com）を手放したら、まんまと業者にドロップキャッチされて、業者が「あなたのコンピュータにウイルスが検出されました」系の詐欺サイトを開設。詐欺サイトへ「ワーナーマイカルのサイトを見ようとしたエンドユーザ」がアクセスして、何かしらの被害が出ている模様。
ちなみに旧ドメイン（warnermycal.com）にアクセスすると、リダイレクト地獄の末にこんな感じになるので、開かないことを強くお勧めします。
Internet Archive Wayback Machineで見る限り、2013年7月にサイトをクローズした後も、1年以上は新ドメイン（www.aeoncinema.com）へ302 Moved Temporarily（＝一時的な移動）でリダイレクトをかけていた模様。旧ドメインの有効期限から推察するに、サイトクローズから1年半以上経った2015年3月頃に旧ドメインを手放したら、4月にドロップキャッチされたものと思われる。
クローズ直後に手放した訳じゃないみたいだし、一応は配慮してたんだね。
ただ2001年ごろに取得したドメインみたいなので、更新料も年々高くなって1年で1万円ちょっと・・・手放したくなる気持ちも分からなくもないけど、結局エンドユーザから「サイトにアクセスしたら、変なページが表示された！」とクレームが来て、トップページにお知らせ出して、といった対応をすることを考えたら、あと何年かはドメイン持ったままの方が安かったんじゃないの？と思う。リダイレクトのログを見てれば、手放す直前に旧ドメインへどれくらいアクセス来てたのか分かるだろうし。
あと、リダイレクトするときのステータスコードを、なぜ301 Moved Permanently（＝恒久的な移動）にしなかったのか！302じゃなくて301にしてれば、ブラウザ側がリダイレクトをキャッシュするので、2回目以降は旧ドメインにアクセスしようとした時点で、最初から新ドメインに行ってたはずで、そうすればエンドユーザが旧ドメインをブックマークしててもまだましだったと思うのに。
しかもちょっと面白いのが、旧ドメインのWhois情報を見ると、「Registrar: DROPCATCH.COM 462 LLC」とある。わっかりやすい名前だな！ドロップキャッチしてるのは、一般人じゃなくて、レジストラなのか！（レジストラ＝お名前.comみたいに、レジストリからドメインを卸してもらって一般人やリセラーに売ってる業者）
Re: ドロップ・キャッチ・システム構築に関する問い合わせ：IT's my business：オルタナティブ・ブログを読んで初めて知ったんだけど、再度売りに出されたドメインをレジストリから確実に買うために存在する、ドロップキャッチ専門のレジストラっていうのが居るんだねー。
最後に、イオンシネマ・・・URLにカンマ入ってる・・・一番大事なところ間違えてるよ！
今後、当社HPへアクセスされる場合は、必ず(www,.aeoncinema.com/)をご利用ください。
