フラッシュカードアプリをQuizletに乗り換える

最近は中国語・スペイン語・英語に加えて簿記のお勉強も毎日のルーティーンに加わったので、覚えものがいっぱい。

単語カード的なもの(フラッシュカード)としては、AnkiWebを中南米前のスペイン語学習のときは使っていましたが、登録したカードをWebでざっと一覧表示できなくて、メンテが不便で使わなくなってしまっていました。

そうはいっても、ペーパーレスで気軽にカード化できる環境はやっぱりほしい。要件としては

  • Webでカード作成と一覧表示ができる
  • たくさんのデータを一気にインポートできる
  • Androidアプリでも使える

こんな感じのが。ということで、

Newmonicを使ってみていた時期もあったんですが、Web版に問題を解くモードがないのが個人的にはいまいちでした。

で、最近見つけたのが

このQuizlet。

有料プランもあるけれど、自分の作ったカードだけで勉強するなら無料で問題なし。広告は入るけれど。

タブ区切りのテキスト貼りつけでもインポートができるのがめっちゃ楽です。スプレッドシートでカードの裏と表を2列に書いて並べておけば、そこからのコピペでインポートできるので、わざわざCSVファイルを生成する手間もかかりません。カード追加があっても、追加分だけコピペすればいいだけやし。

こんなふうに元ネタのスプレッドシートさえ準備しておけば、ざっと一覧するのはそれを直接見るのでもいいし、カードのセットを分割するのとかもインポートのしなおしでどうとでもできるので、管理がしやすいです。

そして、カードのセットごとに個別のURLが割り振られるので、たとえばスペイン語のカードセットと簿記のカードセットをそれぞれ別にブックマークができるのも便利。

ちょっと注意なのは、カードのセットを作ると閲覧できるユーザーのデフォルト設定が誰でもになっていることぐらいかな。見せたくなければ、自分だけに変更できます。

CloudflareではできてPorkbunではできないこととその反対

手持ちの○○○.earthドメインは今、

レジストラ：Porkbun / 権威DNS：Cloudflare

という構成になったんですが、

レジストラと権威DNSを別にすると、遠い将来子ゾーンと親ゾーンの連携まわりで何か不都合があるかもしれない気もしたので、

レジストラ：Porkbun / 権威DNS：Porkbun

という構成をためしてみました。
(Cloudflareはレジストラとしては".earth"ドメインを収容できないので、Cloudflare側に寄せることはできません。)

このあたりの話はネット上に情報が見あたらなかったので、やや詳しめにメモしておきます。

CloudflareではできてPorkbunではできないこと

Cloudflareは機能満載すぎるので、Porkbunではできないことっていっぱいあると思うんですが、ここでは自分の使い方で気づいたところを。

★Email Routing

Cloudflareでは、無料でもメール転送はCatch-Allとかスクリプトで柔軟に振り分けたりとかいろいろできたんですが、Porkbunの無料のメール転送はアドレス数20まででCatch-Allなしと縛りがきついです。

じゃあ「レジストラ：Porkbun / 権威DNS：Porkbun」のままMXレコードだけCloudflareに振り向ければいいんじゃない？

と思ってやってみたんですが、Cloudflareは今自分が権威DNSじゃないことを検知してメール転送を止めてしまいました。残念(>_<)

ちなみに送信元には

host route1.mx.cloudflare.net[162.159.205.11] said: 550 5.1.1
Domain does not exist.

というエラーメールが返りました。

あと、Porkbunのメール転送機能は、Cloudflareとちがって転送先の登録にベリファイが不要です。他人のアドレスでも好き勝手登録できてしまいます。

★DNSのProxyモード

利用者から自分のサーバへのアクセスを、Cloudflareのサーバが中継してくれる機能なんですが、これはPorkbunには見あたりませんでした。

悪いコンピュータから攻撃を受けているときに盾になってくれるしくみでもあります。

★DNSSECの安定運用

レジストラと権威DNSがいっしょになっていた方が長期的に見てDNSSECの安定運用ができるんじゃない？と思っていたんですが、実際Porkbunに寄せてみるとなんかDNSSECが不安定でした。

Porkbunのダッシュボード上は特に問題なく見えるんですが、

DNSSECの状態を可視化するサイトでちょくちょくチェックしてみると、最初はStatus: SECUREになっていたものがいつの間にかStatus: INSECUREに戻ったりと揺れ動きます。

DNSSECをPorkbunに寄せる操作としては、Registry DNSSECの設定を削除してCloudflare DNSSECをONにするだけで、ほかの設定項目は何もないので、設定ミスではないと思います。

この症状は「レジストラ：Porkbun / 権威DNS：Cloudflare」でも「レジストラ：Cloudflare / 権威DNS：Cloudflare」のnikki-san.comでも起こりません。

意外とPorkbunでもできたこと

★CNAME flattening

http://○○○.earth
から
https://www.○○○.earth
にリダイレクトさせるのに、

CNAME flatteningというCloudflareの特殊(？)技術を利用していましたが、Porkbunは内部的にCloudflareのDNSを使っているだけあって、これはできました。

CNAMEとは別に、CNAME flattening専用のALIASというレコードが用意されているので、それを使います。
(AWSのRoute 53でもCNAME flatteningさせたい場合はALIASレコードとして登録していたと思います。)

CloudflareでできなくてPorkbunでできること

★Whois情報の代理公開

これは権威DNSでなく、レジストラとしての話です。レジストラとしてCloudflareを使っているnikki-san.comとの比較です。

CloudflareにはWhois情報の代理公開機能がないので、

シンドメインでWhois代理公開OFFにしたときとだいたい同じく、nikki-san.comは「日本の千葉」の人のものという部分だけ見えてしまっていますが、Porkbunではそれすら隠蔽されていて「アメリカのノースカロライナ州」の誰かのものとして見えるようになっています。

★URL Forwarding

https://○○○.earth
(http"s"の方)
から
https://www.○○○.earth
にリダイレクトさせるのにCloudflareではDNSのProxyモードを利用していましたが、これがない代わりにURL Forwarding機能が使えました。これ、CNAMEでリダイレクトさせるのより柔軟で便利。

たとえば
https://bsky.○○○.earth
を
https://bsky.app/profile/ ○○○.earth
にCNAMEでリダイレクトできるのって、Bluesky側で受け入れのしくみがあるからできることなんですが、そういうしくみのないInstagramとかでも
https://insta.○○○.earth
を無理やり
https://instagram.com/ △△△
にリダイレクトさせることができました。短縮URLの代わりにも使えそう。

構成としては、Porkbunに転送用のWebサーバがいて、HTTPリダイレクトをかけてくれてるっぽいので、「レジストラ：Porkbun / 権威DNS：Cloudflare」の構成に戻しても、CNAMEレコードだけPorkbunに振り向けておけばこのURL Forwarding使えるんじゃない？

と思ってやってみたら、これはできました。

Cloudflare側に追加するCNAMEレコードは、Porkbun上では宛先uixie.porkbun.comのALIASレコードとして自動登録されているものですが、同じく自動登録されている
_acme-challenge.○○○.earth
というTXTレコードもついでにCloudflare側にコピーしておきます。

たぶんPorkbunの転送用Webサーバが○○○.earth宛のHTTPSアクセスを受けるのに、内部的にLet’s Encryptを使っていて、

そのドメイン所有者認証の「DNS-01チャレンジ」のためのレコードじゃないかな？

このレコードは60日に1回はチェックがあるみたいなので、このTXTレコードがないと転送用Webサーバのサーバ証明書の更新ができなくなってしまいそうです。

追記 2024-11-19

このPorkbunのURL Forwarding機能は、「レジストラ：Cloudflare / 権威DNS：Cloudflare」という環境からでも利用可能でした。

そのおかげで
https://nikki-san.com/
から
https://nikki-san.fc2.net/
にリダイレクトできるようになりました。

追記 2025-05-03

CloudflareでもRedirect Rulesを利用すればURL Forwarding相当のことができました。

nikki-san.com取得とBlueskyアカウント開設のお知らせ

9月にこのブログのURLを

https://nikki-san.fc2.net/

に変更していましたが、もしこの作業が失敗してまったくつながらなくなってしまった場合とかに、その状況をお知らせする場所がないなあ・・・みたいなことをまえまえから思っていました。

そういう話と、レジストラも権威DNSもCloudflareな環境の独自ドメインって便利そうだなあ・・・という話が合わさって、

nikki-san.com

というドメインをCloudflareで取ってみました。

そしてこのドメインでBlueskyアカウントも開設。何か書きたいことがあればこのブログに書くと思うので、Blueskyへの投稿はほとんどしないと思うけれど。
(Blueskyだと、ドメインの管理権限がないとこのアカウント名にはできないので、ひと目でアカウントが本物だとわかって便利。)

いつの間にかFC2ブログがサービス終了していた場合でも、このドメインを覚えておくとその後がたどれるかも？

Porkbun(レジストラ)とCloudflare(権威DNS)でのDNSSEC運用

昨日、○○○.earthという独自ドメインが無事に

レジストラ：Porkbun / 権威DNS：Cloudflare

という構成になったので、DNSSECを有効化してみました。

”Porkbun’s 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のシステムを使っているからみたいです。

DNSSECを有効化する

子ゾーンがPorkbun管理じゃない場合、子ゾーンの鍵情報をどうやって親ゾーンのDSレコードに反映させるのかというと、

ただ手入力するしかないようです。

Cloudflareのドメイン管理ダッシュボード > DNS > Settings > DNSSEC > Enable DNSSEC

これでDSレコード用の情報を取得して、Porkbun側のKey Tag・Algorithm・Digest Type・Digest欄に入力します。

ここにも書かれている通り、keyData欄には何も入力しません。

これで子ゾーンのCloudflare側からも親ゾーンのDSレコードが認識できて、DNSSECが無事に有効化できました。

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)側でDNSSECをOFFにする
  • Cloudflare側で鍵更新をする
  • Porkbun側のDSレコードに新しい鍵の情報を登録してDNSSECをONにする

みたいな手順でやることになるんかな。

シンドメインからPorkbunへのレジストラ移管が完了する

シンドメインから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から、キャンセルを行ってください。


11/15 17:07 support@porkbun.com から"porkbun.com | domain security notice - owner info modified"というメールが届く
11/15 17:08 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時に公開される個人情報

シンドメインではもともとWhois情報の代理公開(ドメインの持ち主をユーザー個人ではなくシンドメインだとして公開すること)をしていて、それを移管前にOFFにしていましたが、これOFFでもそんなに個人情報見えなかったです。

お名前ドットコムとかだと、住所や電話番号まで見えてしまうそうなんですが。

移管中にwhoisコマンドで情報を取ってみたところ、ほとんどの項目がREDACTED FOR PRIVACYとなって隠されていて、表示された個人情報は

Registrant Organization
Registrant State/Province
Registrant Country

この3項目だけ。「日本の千葉県の無所属」がばれたぐらいでした。

DNSSECを有効化する

今回のレジストラ移管の目的のひとつだったDNSSECの有効化もしてみたんですが、これが当初思っていたのとちょっとちがった状態に。

さらっと流してもいいんですが、PorkbunとCloudflareの組み合わせでDNSSECを運用する話ってネット上にまったく見あたらなかったので、情報共有のために後日また書きます。

追記 2024-11-16

DNSSECの話です。