（2016/3/27追記）0.88ドルというのは期間限定のキャンペーン価格のようです。普段はもっと高いのかもしれません。
DNSSECって名前は聞くけど詳細は知らないな、というくらいの理解度の人って多いんじゃないでしょうか。実は筆者もそんな一人だったのですが、この連休中に独自ドメインを取得してDNSSEC対応させてみました。DNSSEC対応できるレジストラ・ドメインの組み合わせとしてはNamecheapで.pwドメインを取るのが探した範囲では最安値で、最初の1年間だけ維持するなら0.88ドル、翌年以降更新する場合でも年額7.88ドルに収められることがわかりました。
本稿では一連の顛末を紹介します。
そもそもレジストラやドメインのDNSSEC対応って何？
DNSSECにおいて、レジストラはどういう役割を担うのでしょうか？レジストラの選択がDNSSECの利用にどういう影響を与えるのでしょうか？これを理解するには、DNSSECの仕組みを知る必要があります。
DNSSECを一言で説明すると、従来のDNSレコードに公開鍵暗号による署名を付けることで、問い合わせ結果の正当性を保証するような仕組みです。
この仕組みを成立させるためには署名を行うDNSサーバの公開鍵が本物であることを誰か別の人が保証しなくてはなりません。そこで、DNSSECでは上位の権威サーバが下位ゾーンの公開鍵の正当性を保証するという形になっています。具体的には、DSレコードと呼ばれるリソースレコードに下位ゾーンの公開鍵のハッシュ値を登録することで、下位ゾーンの公開鍵の正当性を担保します。
言い換えると、DNSSEC対応するためにはレジストラ経由で上位の権威サーバ（.jpドメインならJPRSの管理するDNSサーバ）にDSレコードを登録する必要があるのですが、このDSレコードの登録取り次ぎを行っているかどうかはドメインによってもレジストラによってもバラバラという状況です。つまり、独自ドメインと自前のDNSサーバを持っていたとしても、ドメインとレジストラの両方がDNSSECに対応していないとDNSSECは使えないということになります。
国内レジストラのDNSSEC対応状況
まずは日本国内に目を向けてみます。JPドメインについて言うと、ドメイン側は2011年にDNSSEC対応が済んでいます。
一方で、レジストラ側の対応状況は芳しくないようです。JPドメインの指定事業者一覧のページに各レジストラのDNSSEC対応状況のリストがあるのですが、600を超える指定事業者のうちで、2016年3月現在DSレコードの取り次ぎに対応しているのは下記の11サービスのみでした（自己申告制のリストなので、記載していない会社もあるようですが）。DNSSECの普及という観点では寂しい状況ですね…。
- Inetdホスティングサービス
- IP Mirrorグローバルドメイン管理サービス
- IIJ インターネット
- WIXI
- NTTPC
- KDDIインターネット
- スマートバリュー
- Thomson Brandyドメイン名登録サービス
- JPDirect
- ドメインネーム・フォー・ユー
- SANNETインターネットサービス
また、上記11サービスには主要顧客が法人であるものも含まれており、個人だと価格面で敷居が高かったり、そもそも利用できなかったりします。
ちなみに、一見するとお名前.comもDNSSEC対応しているように見えるのですが、単純なDSレコード取り次ぎには対応していないようで、あまりオススメしません。
そんなわけで、DNSSECの実験を安価に行おうと考えた場合は海外ドメイン・海外レジストラを探した方が良さそうな状況だと言えるでしょう。
DNSSEC対応かつ安価な海外レジストラ
海外では多くの大手レジストラがDSレコード取り次ぎに対応しています。CloudFlareの記事「How do I add a DS Record to my registrar?」にDNSSEC対応レジストラとその設定方法が書いてあり、レジストラ選びの参考になりました。
今回、上記の記事に挙げられているレジストラのうち、それなりに安くDNSSEC対応しているレジストラ3つについて比較検討してみました。
GoDaddy
まず世界最大手レジストラとして有名なGoDaddyを検討しました。GoDaddyでDNSSEC対応しているドメインは少なめで、.com/.net/.org/.bizなどです。
GoDaddyの価格は初年度のみ良心的で2年目以降は普通という印象です。通常ルートでは少し安い程度なのですが、プロモーションコードを使うと激安になったりします（ググると.comドメインを初年度0.99ドルで購入できるコードが見つかります）。ただ、登録者の個人情報を隠すオプションが別料金だったり、プロモーションコードを使うとPayPal支払いできなくなったりと細かい点に不満を感じたので結局購入を見送りました。
Gandi
Gandiは少し前まで格安レジストラとして有名だったフランスのレジストラで、今でもボチボチ安い部類になると思います。また、GoDaddyより多くのドメインについてDNSSEC対応しています。
GandiでのDNSSEC対応ドメインのうち最安値は.rocksドメインの初年度5.97ユーロ（約750円）でした。これでも十分安いと思うのですが、実験用には若干高いと考えて見送りました。
Namecheap
最終的にはNamecheapでドメインを買うことにしました。Namecheapは世界第二位のレジストラeNomのリセラーで、eNomリセラーの中では最大手の一つだと思われます。
このNamecheapは名前の通り値段が安いのが特徴で、多くのドメインについて初年度のみ0.88ドルという価格設定を行っています。また、登録者情報を別会社名で隠してくれるサービスも初年度は無料です。
今回、初年度0.88ドルのドメインの中からDNSSEC対応していて2年目以降もボチボチ安いドメインとして.pwドメインを選びました。
Namecheapが他の2つより劣っている点は、DSレコード登録のWebインターフェースが用意されておらず、カスタマーサポート問い合わせ経由で登録依頼する必要があることです。即時性やセキュリティの観点では若干不安だと言えるでしょう（後述するとおりレスポンスは速そうですが）。
CloudFlareのDNSサービスを使えばDNSSEC対応が簡単かつ無料
今回、Namecheapで取得したドメインをCloudFlareのDNSで管理してDNSSEC対応しました。
CloudFlareといえば無料CDNサービスが有名ですが、高機能な無料DNSサービスも提供しています。筆者は趣味で独自ドメインを管理しており、以前はRoute53を使っていたのですが、昨年の2月からCloudFlareを利用しています（参照：「CloudFlareのCNAME FlatteningをGitHub Pagesで使ってみた」）。約1年間の運用で全く不満はありませんし、「CNAME Flattening」のような気の利いた機能が使えるのも良い点だと感じています。
また、CloudFlareは2015年11月からDNSSECに対応しており、簡単にDNSSEC対応ドメインの管理ができるようになっています。今回はこれを試してみたわけです。
DNSSEC設定の作業フロー
ドメイン取得後の実際の作業は下記4ステップになります。
CloudFlare側でDNSSECを有効にする
ネームサーバの登録後、しばらくするとCloudFlareでのドメインの表示が「Status: Active」になります。Activeになってから、「DNS」「DNSSEC」「Enable DNSSEC」をクリックすれば下位ゾーン側のDNSSEC設定が準備できます。
NamecheapのカスタマーサポートにDSレコードの登録を依頼
下位ゾーン側の準備ができたら、レジストラを通じて上位の権威サーバにDSレコードを登録してもらう必要があります。CloudFlareの「DNS」「DNSSEC」「DS Record」から下記のような情報が見えますので、これをNamecheapに伝えるとDSレコードを登録してもらえます（下記画像には一見怖そうな内容が並んでいますが、全て公開情報です）。
この手順についてはCloudFlareの文書「How to add a DS record to Namecheap – CloudFlare Support」も参考にしてください。
既に紹介した通り、NamecheapでのDSレコード登録はカスタマーサポートによる人力対応です。対応の速度やソーシャルハック対策ができているかなど色々不安にはなりますが、筆者が依頼したときは日本時間で日曜日の昼頃だったにもかかわらず30分後に設定完了の連絡が来ました。いつもこんなに速いという保証はありませんが、ご参考まで。
（追記：一部のドメインについては管理画面からDSレコード登録ができるようになったようですが、.pwドメインについては2016年3月時点で未対応でした）
動作確認
DNSSECの設定確認にはDNSVizというサービスが便利です。このサービスは、DNSSECの「信頼の連鎖」をグラフィカルに表示してくれるものです。DNSSECの設定に失敗しているような場合、特定のレコードが「Insecure」と表示されます。
例えば、筆者の取得したドメインの結果は下記URLで確認することができます。グラフ上の全てのノードが「Secure」の表示になっており、正しく設定できていることがわかります。
感想など
自分でDNSSECについて調べたり設定したりしてみて、これ手動運用したら絶対事故るような仕組みだなあ、というのを今さら実感したりしました。つい先日もAPNICさんがやらかしたらしいですが、さもありなんという印象です。
また、自分で試すまではドメインをDNSSEC対応にすると古いOSやアプリケーションで名前が引けないなどのトラブルがあると想像していたのですが、そんなことはありませんでした。
実は仕組みから考えてもトラブルが起こる方が珍しいくらいで、不幸な条件が複数重なって初めて変な状況になるように推測しています。手元の環境で http://ecdsap256sha256.pw/ が見えない、などのトラブルがあった方は教えてもらえると嬉しいです。
有名な事例としてはDNSSEC対応ドメインに対してqmailからのメールが届かないというトラブルがあるようなので、再現実験をしてみたいと考えています（参考：「qmail/netqmailにおける512バイトを超えるDNS応答の不適切な取り扱いについて」）。
