_ うちで使っている .st という TLD って DNSSEC 対応するつもりあるんだろうか、と調べてみたんだけど、どうなんだかわからんかった。それはともかく、調べてるうちにサントメ・プリンシペという国についてまったく何も知らないことに今さらながら気がついた。
_ 島国だというのは知ってたのでカリブ海あたりの中米の小国かなと思ってたんだけど、ぜんぜんそうではなく、西アフリカらしい。で、 ここを見てみると、サントメ・プリンシペに割り当てられた IPv4 アドレスの数は、ゼロ…。なんつーか、いろいろ申し訳ない気持ちになった。.st ドメインって実はけっこう高いんだけど(取得したときは酔ってたのでそんなことはぜんぜん考えてなかった)、このうちどのくらいの額がスウェーデンのレジストリ運営会社にピンハネされることなくサントメ・プリンシペ本国に渡ってるんだろうか。きっと雀の涙ほどの額なんだろうなぁ。
_ さらにそこから発展して外貨獲得の手段として自国ドメインを売ってる国のことを考えてたら、…あー、リビア(.ly)。地理的にはついこの間独裁政権が打倒されたチュニジアとエジプトのちょうど間にあって、やっぱり長期独裁政権が牛耳ってる国。うん、反政府デモが起きないはずがないよね。エジプトのときと同じようにリビアでもインターネットの遮断がおこなわれはじめたらしい。まあ、bit.ly とかがリビア国内に存在するはずがないので直近ではその影響は受けないとは思うけど、問題はその後だよな。報道を見てると政権転覆に成功しそうな勢いに感じるけど、革命の後って旧権力のやったことは全否定されがちなので、.ly を海外に売るとかの政策が転換されることもあるんじゃないかしら。失敗したとしても、すべてが以前のとおりというわけには当然いかんだろうし。
_ つーことで、今現在 .ly を何らかの形で使ってるのであれば、代替のサービスに乗り換える準備はしておいた方がいいんじゃないかしら。それが杞憂だったとしても、それならそれで気にせず今までどおり使えばいいんだし。
_ よその国のドメインが好きに取得できるといっても、あんまり考えなしにほいほい取得するのはよした方がいいんだろうなー。政情とか見極めないと。酔った勢いでドメイン取っちゃうアホがそんなこと言っても何の説得力もないが。
_ v4 の完全枯渇が近付いてきて、v4/v6 デュアルスタックがあたりまえな世の中がもうすぐやってくる。ということで、前々から主張していたことをもう一度叫びたい。
_ 逆引きなんかアテにするな。
_ ISP からエンドユーザーに割り当てられる v6 アドレスに逆引きが設定されることは、ほぼありえない。ちゃんと逆引き設定しようとする ISP がいたとしたら頭がおかしい。v6 ではエンドユーザーに対してはアドレス1個ではなく、たいてい /64 のネットワークが割り当てられる。つまり、たった1ユーザ分のアドレスだけでも ipv4 全アドレスよりはるかに多い。こんなものにいちいち逆引き設定するヤツはアホ。ぜんぶ設定して当たり前、なんていう v4 でのアホな慣習は、v6 ではなくなる。
_ なので、v6 では逆引きなんか完全にあきらめるか、仮に設定するにしてもほんとうに必要なものだけをピンポイントで設定することになる。どうしても必要な場合でも、v6 の逆引き表記は人をバカにしてるとしか思えないような長さで、あの桁数を間違えずに設定できるような完璧人間なんかいるはずがないので、設定したつもりだけど実はできてないなんて事故が頻発する。よって、v6 では逆引きが設定されてる方がむしろ珍しい、という状況になる。たとえば、
てなかんじで google 先生の v6 アドレスは逆引きが設定されていない。% host ipv6.google.com ipv6.google.com is an alias for ipv6.l.google.com. ipv6.l.google.com has IPv6 address 2404:6800:8001::93 % host 2404:6800:8001::93 Host 3.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.0.0.8.6.4.0.4.2.ip6.arpa not found: 3(NXDOMAIN)_ v6 で逆引きが DNS に登録されなくなるということは、つまりクライアントの逆引きに頼ったアクセス制御が使えなくなるということである。v6 でも hosts.allow や .htaccess で逆引きによる制限をすることは可能ではあるけれど、そもそも逆引きが DNS に登録されないのだから実質的には機能しなくなる。
_ とくにメールサーバ。現在はクライアントに逆引きがなければメールを拒否するなんて設定をしているサイトがたくさんある。逆引きで蹴るのは v4 ですら 有害なんだが、逆引きがなくてあたりまえの v6 では v4 以上にやってはいけない。何も考えずこの設定を残したままデュアルスタックにしてしまうと、v6 経由でのメールをほとんど蹴ることになる。デュアルスタックなクライアントからの接続では、MX のプリファレンスが同じなら通常は v6 の方が優先されるので、v6 に逆引きがなければ v4 の方には逆引きが設定してあっても接続を拒否してしまう(v6 で 5xx で蹴られれば v4 にフォールバックしない)。この問題を回避するため、現時点ではメールサーバに関しては v6 でも v4 の悪習にしたがってわざわざ逆引きを設定することが多い。まったくもって無駄な手間。ちなみに、postfix 2.8 以降では
と設定することで、宛先ドメインの MX のプリファレンスが同じで v4/v6 が混在していた場合に v4 を優先させるようにできるので、この問題の影響を軽減できる可能性がある。プリファレンスが異なってたら意味ないので、これを設定しておけば万事解決、というわけではない。smtp_address_preference = ipv4_ その他、メールの v6 アクセス制限まわりでは、逆引きではないけど DNSBL も注意。v4 しか対応していないと、v6 アドレスの DNSBL ルックアップで妙なクエリを出してしまうことがある。v6 対応の DNSBL もどうやら存在してはいるようだけど、いくらでもアドレスを使い捨てできる v6 では DNSBL の意義は薄そうなので、デュアルスタックにするなら止めた方がいいと思う。
_ ということで、本格的に v6 な時代がやってくる前にあらためてお願い。逆引き必須なんて考えはとっとと捨ててください。逆引きに依存したサーバ設定は見直してください。
_ うちのドメインは酔った勢いで取ったと この前ちらっと書いたけど、実はもうひとつ酔って取得したドメインがございまして。別に飲むとドメインを取るクセがあるわけじゃないはずだが、少なくとも素面でドメインを取ったことはない:-)。つい先月、.jp で DNSSEC がはじまっちゃったなー、となんやかやしてたら、気がついたら何かボタン押してた。使い道なんか何もないのにドメイン取ってもどうしようもないけんだけどなぁ。
_ 使い道はないけどテストがてら署名しとくか、と思ったんだけど、手作業でやるのめんどくせ。ツールを使うにも、OpenDNSSEC は大袈裟すぎるし、うちは NSD なので BIND の smart signing や auto-dnssec は使えないし (*1)。
_ つーことで、ゼロから書いた。仕事でも似たようなのをちらっと書いたことがあるけど、そいつは一切流用せずフルスクラッチで(内部の設計をだいぶ変えたので流用しようにもできなかった)。その後しばらく使ってみて問題なさげだったので、 スクリプトを公開しときます。実際にこいつで動いてるドメインはこんな状況。
chigumaya.jp は 2048bit の KSK と 1024bit の ZSK を使う一般的なやりかただけど、sub.chigumaya.jp (*2)は 1024bit な単一鍵でゾーン全体を署名していて、親ゾーンが同じサーバにあるので DS の更新も自動でおこなうようになってる。んで、さらに親ゾーンは ldns で鍵生成/署名していて不在証明は NSEC3、子ゾーンは BIND 付属のツールで署名して NSEC。このへんは同じスクリプトで設定をちょっといじるだけで切り替えられるようになってる。> drill -S -k ~/root.key sub.chigumaya.jp SOA ;; Number of trusted keys: 1 ;; Chasing: sub.chigumaya.jp. SOA DNSSEC Trust tree: sub.chigumaya.jp. (SOA) |---sub.chigumaya.jp. (DNSKEY keytag: 61831 alg: 8 flags: 257) |---sub.chigumaya.jp. (DS keytag: 61831 digest type: 2) |---chigumaya.jp. (DNSKEY keytag: 29130 alg: 8 flags: 256) |---chigumaya.jp. (DNSKEY keytag: 13780 alg: 8 flags: 257) |---chigumaya.jp. (DS keytag: 13780 digest type: 2) |---jp. (DNSKEY keytag: 33696 alg: 8 flags: 256) |---jp. (DNSKEY keytag: 1369 alg: 8 flags: 257) |---jp. (DS keytag: 1369 digest type: 1) | |---. (DNSKEY keytag: 21639 alg: 8 flags: 256) | |---. (DNSKEY keytag: 19036 alg: 8 flags: 257) |---jp. (DS keytag: 1369 digest type: 2) |---. (DNSKEY keytag: 21639 alg: 8 flags: 256) |---. (DNSKEY keytag: 19036 alg: 8 flags: 257) ;; Chase successful_ なお、DNSSEC をブラックボックス化して詳しいことを知らなくても使えるようにするためのものではないのでそのへんは勘違いしないように。ちゃんとわかっていることが前提。 前にも書いたように、ふつーの人は自分でやろうとせず外部委託するのが無難。