こんにちは、ネットエージェント株式会社、大阪支社の山口です。今回は DNSCurve について軽く紹介したいと思います。
-----
DNS のレコード改竄対策として DNSSEC が少しずつ認知されつつありますが、とはいえ、その複雑さから導入にいまひとつ踏み切れない管理者の方も多いかと思います。このような懸念に対して DNS サーバの djbdns や HTTP サーバの publicfile などで知られるイリノイ大学の D. J. Bernstein 氏が、DNSSEC の諸問題を指摘するとともに、対案として DNSCurve を提案しています。
DNSSEC と DNSCurve の主な違いとして以下の2点が挙げられます。
- DNSSEC がキャッシュサーバに保持される DNS リソース情報が正しいものであることを確認するため、応答に電子署名を施しているのに対して、DNSCurve では別ホストのキャッシュサーバを用いずに権威サーバと直接暗号化通信を行うことで正しい値を得ようとします。
- DNSSEC が電子署名の公開鍵や署名データに新たにリソースレコードを追加してそれぞれに対応するためにソフトウェアの大規模な変更が必要だったのに対し、DNSCurve では問合せや応答のレコード数に変化がないためプロキシの実装は比較的容易だと言われています。
DNSCurve のパケットがどのような形式になっているか、公開されているドラフト「DNSCurve: Link-Level Security for the Domain Name System」（2010年8月で期限切れ）を参照しながら確認してみます。
DNSCurve の暗号化には楕円曲線暗号を用いた公開鍵暗号が使用されています。暗号化に利用される Curve25519（Diffie-Hellman 鍵共有）、Salsa20（ストリーム暗号）、Poly1305（メッセージ認証）の各アルゴリズムについては、Bernstein 氏の論文で説明されています。
通信には 256bits の鍵と、192bits の nonce と、128bits の MAC が使用されます。サーバ側の鍵は、鍵を BASE32 エンコードした先頭51文字をプレフィクス "uz5" のうしろにつけたものをネームサーバのホスト名として登録します（→4）。
クライアントは、"uz5" で始まる 54bytes のホストパートを持つ NS レコードがある場合に DNSCurve 通信を行います。
問合せパケットは以下のような構成になります（→6.1）。
- 識別文字列 "Q6fnvWj8"
- クライアントの公開鍵 32bytes(256bits)
- クライアント nonce 12bytes(192bits)
- 暗号化した問合せパケット
応答パケットの場合は以下のとおりです。
- 識別文字列 "R6fnvWJ8"
- クライアント nonce 12bytes(192bits)
- 応答 nonce 12bytes(192bits)
- 暗号化した応答パケット
TXT レコードの問合せの場合は、問合せ名にnonce、暗号化した問合せパケット、クライアントの公開鍵を含む形式になります (→6.2)
DNSCurve を試すには、まず既存のコンテンツサーバを DNSCurve に対応させるプロキシ CurveDNS を使用します（フリーのコンテンツサーバ実装 gdnsd も DNSCurve 対応しているようです）。
そして、キャッシュサーバにて、Bernstein 氏の暗号アルゴリズムの実装された NaCl ライブラリをビルドし、先述のドラフトを書いた OpenDNS Inc. の Matthew Dempsky 氏が公開している djbdns 用のパッチ（http://shinobi.dempsky.org/~matthew/patches/djbdns-dnscurve-20090602.patch）を適用します。その後、conf-cc と conf-ld に、それぞれビルドした NaCl ライブラリのインクルードパス、ライブラリパスを追加してビルドします。
DNSCurve は、DNSSEC に比べて従来の設定からの変更が小幅なため導入に際してのトラブルは比較的少ないというメリットが見込めます。とはいえ、標準化プロセスを経ておらず、実装もまだ数が少なく、サイトごとのキャッシュサーバではなく各クライアントごとに再帰問合せを行うことによるトラフィックの増加や、鍵の更新手順などの運用上の問題等も議論が続くものと思われます。今後の状況に注目していきたいところです。
