9月にこのブログのURLを
に変更していましたが、もしこの作業が失敗してまったくつながらなくなってしまった場合とかに、その状況をお知らせする場所がないなあ・・・みたいなことをまえまえから思っていました。
そういう話と、レジストラも権威DNSもCloudflareな環境の独自ドメインって便利そうだなあ・・・という話が合わさって、
というドメインをCloudflareで取ってみました。
そしてこのドメインでBlueskyアカウントも開設。何か書きたいことがあればこのブログに書くと思うので、Blueskyへの投稿はほとんどしないと思うけれど。
(Blueskyだと、ドメインの管理権限がないとこのアカウント名にはできないので、ひと目でアカウントが本物だとわかって便利。)
いつの間にかFC2ブログがサービス終了していた場合でも、このドメインを覚えておくとその後がたどれるかも？
昨日、○○○.earthという独自ドメインが無事に
レジストラ：Porkbun / 権威DNS：Cloudflare
という構成になったので、DNSSECを有効化してみました。
PorkbunにはCloudflare DNSSECという設定項目があるので、てっきり子ゾーン(権威DNSのCloudflare)の鍵更新があったときに親ゾーン(Porkbun)側のDSレコードに新しい鍵情報を反映させてくれたりする機能なんだと思っていました。
Warning
This guide walks through how to enable DNSSEC on a domain using Porkbun’s nameservers. If you are using external nameservers, please refer to the following guide instead: How to install DNSSEC
でも説明をよく読むとこんな注意書きが。Cloudflare DNSSECは子ゾーンがPorkbunのときだけ使える機能のようです。
じゃあなんでCloudflareって名前がついてるん？と思ったんですが、
Porkbunの提供するDNSサービス自体が内部的にCloudflareのシステムを使っているからみたいです。
子ゾーンがPorkbun管理じゃない場合、子ゾーンの鍵情報をどうやって親ゾーンのDSレコードに反映させるのかというと、
ただ手入力するしかないようです。
Cloudflareのドメイン管理ダッシュボード > DNS > Settings > DNSSEC > Enable DNSSEC
これでDSレコード用の情報を取得して、Porkbun側のKey Tag・Algorithm・Digest Type・Digest欄に入力します。
ここにも書かれている通り、keyData欄には何も入力しません。
これで子ゾーンのCloudflare側からも親ゾーンのDSレコードが認識できて、DNSSECが無事に有効化できました。
さっそく名前解決の様子をWiresharkでキャプチャして動作のちがいを見てみようと思ったんですが、ふつうと何も変わらない。あれ？
ざっくりDNSSECというのは、DNSの各レコードに電子署名をつけることで、レコードとその署名を比較して「正しい」かどうか検証できるようにする技術です。
調べてみると、この「電子署名をチェックして検証する」という動作を端末(ブラウザ・OSとも)側は通常やらないみたいなんです。検証するのはDNSリゾルバから先。しかもやるかやらないかは任意。
てことは、悪意あるWi-FiルータのDHCPで、偽装DNS情報を配布するみたいなケースには無力ってことか〜。その偽装DNSがDNSSECの検証をせずににせ情報を流せば、端末はそれをうのみにしてしまうわけなので。
がんばってブラウザにアドオンを入れれば検証できたりするみたいんですが、それだと「がんばらないふつうの人も含めてみんなDNS偽装にだまされないように」することはできないのであんまりおもしろくないなあ・・・
DNSSECの状況を可視化できるサイトで、各レコードがStatus: SECUREになっていることは確認できたので、ちゃんと外部から見ても動作はしているようです。
親ゾーン(Porkbun)で鍵更新があった場合、鍵そのもの関連以外で影響するのはDSレコードに対する署名(RRSIGレコード)だけなので、親ゾーンの中で閉じる話です。ここはユーザーが手出しできないところなので、自動でうまいことやってくれるんでしょう。
問題は子ゾーン(Cloudflare)で鍵更新があった場合。親ゾーンのDSレコードに新しい鍵の情報を登録しなおすことになるけれど、これがPorkbunでは手作業でしかやりようがない。
で、どういうタイミングで鍵更新があるのか調べてみたんですが、
Cloudflareは、現在使用されているほとんどのRSA鍵よりも強力な楕円曲線アルゴリズムECDSA P-256を使用しています。署名の生成に使用されるCPUの使用量が少ないため、より効率的に署名をその場での生成が可能です。通常、DNSSECの一部として、ゾーン署名鍵 (ZSK) と鍵署名鍵 (KSK) との2つの鍵が使用されます。最も単純なレベルでは、ZSKはクエリに応答して提供されるDNSレコードの署名に使用され、KSKは真正性を確保するためのZSKを含めてDNSKEYの署名に使用されます。
現在、Cloudflareは、すべてのDNSSEC署名にグローバルに共有ZSKとKSKを使用しています。このような強力な暗号化アルゴリズムの使用によりこの鍵セットの安全性に確信を持っているため、少なくともセキュリティ上の理由からZSKやKSKを定期的にローテーションする必要はないと考えています。
あ、そうなん！？鍵の自動更新ってないんや！
子ゾーンの鍵は、アルゴリズムがECDSAで鍵長512ビットなので、
暗号強度としてはRSAの15360ビットと同等ということみたい。今の時代としてはめっちゃ強いけど、楕円曲線暗号に量子耐性はないそうなので、さすがに量子コンピュータが使い物になる時代までにはこの鍵は更新されそうかな。
しかしながら、ポリシー上、これらの鍵を特定の間隔でローテーションする必要があるお客様もいます。このため、新しいFoundation DNSの高度なネームサーバーには、必要に応じてアカウントごと、またはゾーンごとにZSKとKSKの両方をローテーションする機能が追加されています。これはまずAPI経由で利用でき、続いてCloudflareダッシュボードから利用できるようになります。そのため、DNSSEC鍵のローテーションに関する厳格なポリシー要件を持つお客様も、Cloudflare Foundation DNSを使用してその要件に対応することができます。
ふむふむ。今はCloudflareダッシュボードにそういう機能は見あたらないので、今後の話なんやろけど、ブラウザから手作業で更新できるようになるってことか。
もしそうなって鍵更新をしたくなった場合は、
みたいな手順でやることになるんかな。
シンドメインからPorkbunへのレジストラ移管が今日完了しました。ということで、
レジストラ：シンドメイン / 権威DNS：Cloudflare
↓
レジストラ：Porkbun / 権威DNS：Cloudflare
という構成になりました。
11/10 17:02 Porkbunサイト上でドメイン移管操作
11/11 10:00 support@wpx.ne.jp
から以下のようなメールが届く
XSERVER Inc. - wpX は 2024-11-11 10:00:03 に他社レジストラへの、
トランスファー申請を受け付けました。このメッセージは、WHOIS データベースで、このドメインの
登録者( Registrant contact )としてリストされているアドレスに対して送信されています。トランファー申請を進める場合は、このメールへの返答や手続きは必要ありません。
トランファー申請のキャンセルを希望する場合は、 2024/11/14 17:02:06 までに
下記URLから、キャンセルを行ってください。
support@porkbun.com
から"porkbun.com | domain security notice - owner info modified"というメールが届くsupport@porkbun.com
から"porkbun.com | Transfer In Notification - Transfer Complete"というメールが届くということで、所要時間は5日と6分でした。うち4日はキャンセル申し出待ちってことになるかな。移管元レジストラによっては、「もう進めて」と意思表示することですぐに移管できるところもあるそうなんですが、シンドメインでそういうことはできないそうです。サポートに確認しました。
権威DNSとしてCloudflareを指し示すNSレコードのTTLは1日あるし、おそらくダウンタイムなしで移行できたと思います。
(11/10の移管操作のときからExPingで疎通確認を続けていたんですが、今日の移管完了後に見るとExPingが落ちていました。何日かはちゃんと動いていたのに・・・)
そしてWhois情報上で、ドメインの有効期限が1年延びていました。
シンドメインではもともとWhois情報の代理公開(ドメインの持ち主をユーザー個人ではなくシンドメインだとして公開すること)をしていて、それを移管前にOFFにしていましたが、これOFFでもそんなに個人情報見えなかったです。
お名前ドットコムとかだと、住所や電話番号まで見えてしまうそうなんですが。
移管中にwhoisコマンドで情報を取ってみたところ、ほとんどの項目がREDACTED FOR PRIVACYとなって隠されていて、表示された個人情報は
Registrant OrganizationRegistrant State/ProvinceRegistrant Country
この3項目だけ。「日本の千葉県の無所属」がばれたぐらいでした。
今回のレジストラ移管の目的のひとつだったDNSSECの有効化もしてみたんですが、これが当初思っていたのとちょっとちがった状態に。
さらっと流してもいいんですが、PorkbunとCloudflareの組み合わせでDNSSECを運用する話ってネット上にまったく見あたらなかったので、情報共有のために後日また書きます。
先週修理に出していたPECOですが、おととい修理が終わったと連絡があったので、今日取りに行ってきました。
前後輪とも新しくなって、スーパーボール並みの弾力が戻ってきました！
PECOは特に後輪のつくりが独特なので、交換がとても大変だったそうです。年齢的なこともあって、もう次は無理じゃないかと言われていました。
今回はややこしい注文受けてもらってありがとうございます(>_<)
リペアムゲルでのノーパンク処理ができて、PECO対応できるところってもうないかもしれないので、これが最後の修理になるかも・・・今回のタイヤも持ってあと4年。
もういよいよPECOが動かないとなったら、そのときはglafitのGFR-02かなあ・・・
「空はなぜ青い？」が子供からの定番質問として紹介されているのを何度か聞いたことがあります。
でも子供がそんな疑問を本当に持つんかな？となんとなく思っていました。
それを言うなら、「葉っぱはなぜ緑色？」とか「卵の黄身はなぜ黄色い？」とか無限のバリエーションがありそうやけど、そういうのはたぶん定番になってないです。
なのでレイリー散乱という現象のことを知っている大人が逆算して「空はなぜ青い？」を定番化させたんじゃないんかな？子供が疑問を持った体(てい)にして。
でも今日青空をぼーっと見ていて、今さら気づきました。
雲が白いのは、そこに何か白い物体があるからだと思う。
でも何もないところが青く見えているけど、あれは何？空の果ての壁の色？
そういう疑問か・・・
雑に答えると、「空気の色」ってことになるんやろなあ。夕焼けで赤くなるのも含めて。