ネットエージェント株式会社 オフィシャルブログ

山口尋久

軽量トランスポートセキュリティ CurveCP を試す

 こんにちは、ネットエージェント株式会社、大阪支社の山口です。
 地震の被害、影響により当ブログの更新が 2~3 週間ほど滞っていましたが、本日より、2 週間に 1 回というこれまでとは少し頻度を抑えた形ではありますが、更新を再開させていただこうと思います。また繰り返しになりますが、被害を受けられました皆様に心よりお見舞い申し上げますと共に、東北地方を始めとした東日本全体の一日も早い復旧を心よりお祈り致します。

 さて、今回は、前回紹介した DNSCurve の暗号化部分を一般化した実装 CurveCP のα版実装をのぞいてみたいと思います。

-----

 CurveCPDNSCurve で使われているトランスポート層のセキュリティ拡張プロトコルを DNS 以外の通信にも拡張すべく、現在開発中のプロトコルです。CurveCP を利用したアプリケーションはまだないようですが、パケット構成やメッセージフォーマットを確認できる実装が公開されています。私も少し触ってみたので、その導入手順を以下に記します。
 まず NaCl(Networking and Cryptography library) ライブラリをダウンロードして展開・ビルドします。本稿執筆時点でのバージョンは 20110221 でした。

$ wget http://hyperelliptic.org/nacl/nacl-20110221.tar.bz2
$ bzcat nacl-20110221.tar.bz2 | tar xf -
$ cd nacl-20110221
$ ./do

 今回は動作を試すだけなので、ビルドしたディレクトリのままで使います。サーバ用(192.0.2.1)とクライアント用(192.0.2.2)に 2 台同じ設定で用意しました。

$ export PATH=${PATH}:`pwd`/build/`hostname -s`/bin
$ mkdir -p ~/tmp/curvecp
$ cd ~/tmp/curvecp

 サーバ側の鍵を生成します。

$ curvecpmakekey serverkey
$ ls -AFR serverkey
.expertsonly/ publickey

serverkey/.expertsonly:
lock noncecounter noncekey secretkey

 サーバ側の公開鍵をクライアントへコピーします。

$ curvecpprintkey serverkey > serverkey.hex
$ scp serverkey.hex 192.0.2.2:~/tmp/curvecp

 用意ができたので実際に通信をしましょう。今回試したα版では、通信前の準備などを行うパケット構成と、実際に送受信するデータの整形を行うメッセージ構成にそれぞれコマンドが用意されています。コマンドフォーマットは以下になります。

 □curvecpserverサーバ側パケット構成プログラム
  -snameサーバ名
  -keydirサーバ側鍵を保持するディレクトリ
  -ipaddrIPアドレス
  -portポート番号
  -extこの通信の識別用サーバ側拡張文字列
  -progクライアント接続時に実行するプログラム

 □curvecpclientクライアント側パケット構成プログラム
  -snameサーバ名
  -pubkeyサーバ側の公開鍵(文字列)
  -ipaddrIPアドレス
  -portポート番号
  -extこの通信の識別用サーバ側拡張文字列
  -prog接続時に実行するプログラム

 □curvecpmessageクライアント側パケット構成プログラム
  -prog通信時に実行するプログラム

 curvecpserver を使い、サーバ側で date コマンドを実行するよう待ち受け設定します。

$ curvecpserver server.example.com serverkey 192.0.2.1 10000 [折返し]
12345678901234567890123456789012 curvecpmessage date

 次にクライアント側で、サーバから送られてきた内容を表示するコマンド(curvecpclient)を実行します。

$ curvecpclient server.example.com $(cat serverkey.hex) [折返し]
192.0.2.1 10000 12345678901234567890123456789012 [折返し]
curvecpmessage -c sh -c 'cat <&6'

 実行結果をキャプチャしたものを curvecp_tcplog.txt に置いておきますので興味があればぜひ見てみてください。パケットフォーマットなどが確認できます。

-----

 今回 CurveCP のサンプル実装を実行してみました。公開鍵文字列と、鍵と対になるサーバ側の拡張文字列が事前にクライアント側へ渡っていれば暗号化通信が可能になります。暗号化通信の特徴が分かったからといって中身を閲覧できるわけではありませんが、参考になればということで紹介いたしました。

DNSCurveの紹介

 こんにちは、ネットエージェント株式会社、大阪支社の山口です。今回は DNSCurve について軽く紹介したいと思います。

-----

 DNS のレコード改竄対策として DNSSEC が少しずつ認知されつつありますが、とはいえ、その複雑さから導入にいまひとつ踏み切れない管理者の方も多いかと思います。このような懸念に対して DNS サーバの djbdns や HTTP サーバの publicfile などで知られるイリノイ大学の D. J. Bernstein 氏が、DNSSEC の諸問題を指摘するとともに、対案として DNSCurve を提案しています。

 DNSSEC と DNSCurve の主な違いとして以下の2点が挙げられます。
  1. DNSSEC がキャッシュサーバに保持される DNS リソース情報が正しいものであることを確認するため、応答に電子署名を施しているのに対して、DNSCurve では別ホストのキャッシュサーバを用いずに権威サーバと直接暗号化通信を行うことで正しい値を得ようとします。
  2. 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 通信を行います。
dnscurve_1_request_pkt 問合せパケットは以下のような構成になります(→6.1)。
  • 識別文字列 "Q6fnvWj8"
  • クライアントの公開鍵 32bytes(256bits)
  • クライアント nonce 12bytes(192bits)
  • 暗号化した問合せパケット

dnscurve_2_response_pkt 応答パケットの場合は以下のとおりです。
  • 識別文字列 "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 に比べて従来の設定からの変更が小幅なため導入に際してのトラブルは比較的少ないというメリットが見込めます。とはいえ、標準化プロセスを経ておらず、実装もまだ数が少なく、サイトごとのキャッシュサーバではなく各クライアントごとに再帰問合せを行うことによるトラフィックの増加や、鍵の更新手順などの運用上の問題等も議論が続くものと思われます。今後の状況に注目していきたいところです。

DNSSEC応用の一例「Phreebird Suite」の紹介

 こんにちは、ネットエージェント株式会社、大阪の山口です。
 今回は、先日の Black Hat Abu Dhabi 2010 で Dan Kaminsky の発表 において使用されたツール群 Phreebird Suite について紹介させていただきます。
 Dan Kaminsky は Black Hat での発表(スライド)にて、まず問題提起として「異なる組織間の認証」が困難であることを挙げています。組織内での認証は設定が容易であるのに対し、組織外から来た人を認証する仕組みは、まだ必要に応えるに十分整備されてるとは言い難いでしょう。そのため、政治的に介入が難しく技術的にも制約されており、既に十分に普及していて、なおかつ、それなりに信頼されている DNS に、DNSSEC の機能が備わったら認証として使えるのではないか、というのが彼の提案であり、そのコンセプトコードが Phreebird Suite というツール群です。
 「異なる組織間の認証」にDNSを使うという彼の提案内容もなかなか興味深いものですが、発表にもその一部しか記述されていないこともあり今後の発表を待つとして、今回は公開されたツール群 Phreebird Suite について紹介したいと思います(興味がある方は彼のスライド資料もご参照ください)。

-----

 Phreebird Suite の中でも特に DNSSEC の導入を容易にできるのか、という問いに対する答えとして提示されているのが、phreebird コマンドです。phreebird コマンドは権威サーバとして設定された DNS サーバの前段に設置して、DNSSEC 署名を代行するプロキシとして動作します。既存の DNS コンテンツサーバでの署名が何らかの理由でできない場合に、当面の回避策として導入できます。
 以下に phreebird コマンドを試した経過を記します。テストには FreeBSD のインストールされた PC を使用しました。本稿執筆時点での最新バージョンは 1.02 です。
 アーカイブを展開したら、各ファイルがCRLF(改行)になっていたので、行末のCRを削除しました。また、依存ライブラリ類のtar ballが配布アーカイブに含まれていますが、今回は ports システムを使ってインストールしました。

# portmaster dns/ldns devel/libevent devel/libghthash dns/unbound

 さらに、検証の都合上、ポート番号を指定できた方が都合がよかったのでコマンドラインオプションを追加したり、(libevent のドキュメントによると event_free() より event_del() がふさわしいようだったので)コードを若干書き変えたり、コンパイルエラーが出ないように修正するなどして、以下のようなパッチをあて、ビルドしました。

(※)編注:以下、1行を折り返す場合は[折返し]と表示しています。

--- ./phreebird.c.orig  2010-11-19 14:55:00.000000000 +0900
+++ ./phreebird.c 2010-11-19 14:55:00.000000000 +0900
@@ -61,6 +61,7 @@ struct phreebird_opts_struct
unsigned short http_port;
// for TCP
int listensock;
+ int listenport;

};
typedef struct phreebird_opts_struct phreebird_opts;
@@ -163,7 +164,7 @@ int main(int argc, char **argv){

set_defaults(opts);

- while ((c = getopt(argc, argv, "k:gdb:?m:")) != -1) {
+ while ((c = getopt(argc, argv, "k:gdb:?l:m:")) != -1) {
switch (c){
case 'k':
LDNS_FREE(opts->dnskey_fname);
@@ -186,6 +187,9 @@ int main(int argc, char **argv){
//opts->backend_ip = strdup(optarg);
//if(p){opts->backend_port = atoi(p+1);}
break;
+ case 'l':
+ opts->listenport = atoi(optarg);
+ break;
case 'm':
nsec3_rater.max = atoi(optarg);
break;
@@ -332,9 +338,9 @@ int init_udp_socket(unsigned short port)

int init_sockets(phreebird_opts *opts){

- opts->stubsock = init_udp_socket(53);
+ opts->stubsock = init_udp_socket(opts->listenport);
opts->backsock = init_udp_socket(0);
- opts->listensock = init_tcp_socket(53);
+ opts->listensock = init_tcp_socket(opts->listenport);
return 1;
}

@@ -460,7 +466,7 @@ void clientcallback(int clientfd, short
amount_read = read(clientfd, &to_read, 2);
if (amount_read < 2) {
close(clientfd);
- event_free(store_cache->clientevent); // FREE2
+ event_del(store_cache->clientevent); // FREE2
return; // MIDRET, ok because no alloc before here
}
buffer = calloc(to_read, 1); //ALLOC3
@@ -1157,7 +1163,7 @@ int do_sign(ldns_rr_list *dest, ldns_rr_
bool rate_exceeded=false;


- if(ldns_rr_list_rr_count(src)==0){ return; }
+ if(ldns_rr_list_rr_count(src)==0){ return 0; } // make compiler happy

// XXX *must* allow cache size to be specified, [折返し]
and allow records to expire!
if(rrsig_cache == NULL){
@@ -1342,6 +1348,7 @@ void do_help(){
fprintf(stdout, "Options:
");
fprintf(stdout, " -k : Filename of private key (default: dns.key)
");
fprintf(stdout, " -d : Activate debugging
");
+ fprintf(stdout, " -l : [折返し]
Use the given port for listen instead of port 53
");
fprintf(stdout, " -m : Set max [折返し]
# of unique NSEC3 responses to sign a second (Default: 200)
");
fprintf(stdout, "Dangerous Options:
");
fprintf(stdout, " -g : Generate private key
");

 ビルド後、-?オプションを付けて phreebird コマンドを実行すると、使い方が表示されます。

$ bin/phreebird -?
Phreebird 1.02: DNSSEC Supplementation Engine.
Author: Dan Kaminsky, dan@doxpara.com
WARNING: THIS IS EXPERIMENTAL CODE THAT SHOULD NOT BE.
DEPLOYED ON PRODUCTION NETWORKS. Yet.
Options:
-k : Filename of private key (default: dns.key)
-d : Activate debugging
-l : Use the given port for listen instead of port 53
-m : Set max # of unique NSEC3 responses to sign a second (Default: 200)
Dangerous Options:
-g : Generate private key
-b backend_ip:backend_port : Declare the location of the backend to proxy
(DO NOT ALLOW INTERNET TO SPOOF BACKEND TO PHREEBIRD.)

 表示にしたがって -g オプションを付けて実行すると、DNSSEC のためのキーデータが作成されます。


$ bin/phreebird -g
Generated key: dns.key. Restart without -g.
$ cat dns.key
Private-key-format: v1.2
Algorithm: 7 (RSASHA1_NSEC3)
Modulus: viLKSDOnIjGY52is9XyTJhY4LG2FCHP7bA8
VWY5g+ChoHI9omMmChln7vQXJfEL0VyWjmbHE2xWzkhx
lS8IJvnly0W0I2iyavofFXCzM3BeRvKcgLHdP7f8bNXA
lDUoPu2Gz7pd+S7EoRmVI/zxKjgJfsyUeawemLdAhUlw
kfaM=
PublicExponent: AQAB
PrivateExponent: Rjb+0I8Sp5P9TWfgh3+Lr8MA15d
SS37ZWFxxm/LyaHIzkGh9Tf8MjqToTDO45oSrSwuBUR7
O/cET4V9PIRz1D5k3VAphD+ok7KHzsbZVMPkAo/Sc5Gs
wIO/XfMM7RJQorrxUKN1ynILfZXc0ynEQm0FQf913Rgn
RQ9Q1WgTs4YE=
Prime1: 4eM+pW6qHxEEUpxZBkWP5MEjzupU582Sxcst
GIfUbhtSEM8JS3Kii8QR23EeiOtWysL01HFwt3wSjVzP
RY1HAw==
Prime2: 13t2ad9tAncElJEpzQg5qhelwdcZCQpcv1Oq
Nv4NQ6UBlLrIuG34QEff7p/R6icsBuTvFBMvJcFpqvdN
sHxc4Q==
Exponent1: d0YTtSy6/Y5xtuFBjLM8aLCnJMHNNVzyL
Ci9Vh+axsz8R03a/ZC5TY2pVDLlyaxidsv8lRSVTP1hm
m0wMOyJWw==
Exponent2: GIm3r1DBEiHJhL2PHAkOv/7XYl6DPFNQw
nzdikud6REWQACRMOdc+Lz2lC7g8aAqVFKnowqYON1wk
gZ9c1aGIQ==
Coefficient: TWr93R5sESCkQBN6lkgjc9ulRbPFsUF
kkhUnTjJeFNSizgRq5liiEcHsxmNWwU1TSRq2wUlPfuM
OhFtWNvFB1A==

 これを使って、phreebird が DNSSEC プロキシとして動作する様子を確認します。テスト用にゾーン情報を以下のように作成しました。

$ cat /usr/local/etc/nsd/netagent.example.zone
$ORIGIN netagent.example.
$TTL 86400

@ IN SOA ns.netagent.example. root.netagent.example. (
2010111902 ; serial number
8h ; refresh
2h ; retry
10d ; expire
1d ; min ttl
)

NS ns.netagent.example.
MX 10 mail.netagent.example.

ns IN A 192.0.2.1
mail IN A 192.0.2.1

 これを、適当なコンテンツサーバに登録し、50053番ポートで待ちうけます。

$ dig +noquestion +norec +multiline [折返し]
-p 50053 @localhost netagent.example ns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49693
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
netagent.example. 86400 IN NS ns.netagent.example.

;; ADDITIONAL SECTION:
ns.netagent.example. 86400 IN A 192.0.2.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#50053(127.0.0.1)
;; WHEN: Fri Nov 19 15:56:22 2010
;; MSG SIZE rcvd: 83

 phreebird コマンドを起動します。-b 127.0.0.1:50053 はデフォルト値なので、省略可能です。

$ bin/phreebird -b 127.0.0.1:50053 -l 10053

 動作を確認します。

$ dig +nocmd +noquestion +norec +multiline [折返し]
-p 10053 @localhost netagent.example ns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34472
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
netagent.example. 86400 IN NS ns.netagent.example.

;; ADDITIONAL SECTION:
ns.netagent.example. 86400 IN A 192.0.2.1

;; Query time: 3 msec
;; SERVER: 127.0.0.1#10053(127.0.0.1)
;; WHEN: Fri Nov 19 16:09:33 2010
;; MSG SIZE rcvd: 118

$ dig +nocmd +noquestion +norec +multiline [折返し]
+dnssec -p 10053 @localhost netagent.example ns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56532
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
netagent.example. 86400 IN NS ns.netagent.example.
netagent.example. 86400 IN RRSIG NS 7 2 86400 20101217071059 (
20101119071059 10970 netagent.example.
odQyPOP5s1b0dIeVr9SrFs7fZn0YQ2iMlxKLmaMwagZB
J8z3MK4PkK8kBXJKN6brMB77VtXlwTgYpkgWn+y/oUpb
W7yKm6R7xZVxaBKE45E/DL4A7FkTS06yPf8p0peB0nQ7
F3+QycFArFSC/nEMnsQWBza7eL59sjoW0/2eJg8= )

;; ADDITIONAL SECTION:
ns.netagent.example. 86400 IN A 192.0.2.1

;; Query time: 3 msec
;; SERVER: 127.0.0.1#10053(127.0.0.1)
;; WHEN: Fri Nov 19 16:10:59 2010
;; MSG SIZE rcvd: 321

 +dnssec で問い合わせると RRSIG RR が付加されています。
 存在しない名前を引くと、NSEC3 で不存在を示す応答が返ってきます。

dig +nocmd +noquestion +norec +multiline [折返し]
+dnssec -p 10053 @localhost [折返し]
nonexistent.netagent.example
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16472
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; AUTHORITY SECTION:
netagent.example. 86400 IN SOA ns.netagent.example. root.netagent.example. (
2010111902 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
864000 ; expire (1 week 3 days)
86400 ; minimum (1 day)
)
netagent.example. 86400 IN RRSIG SOA 7 2 86400 20101217071342 (
20101119071342 10970 netagent.example.
LbDxWtMJSwbhP/zlLKs15SYZ7SCu8XRE3hnEzYjIp/HT
fqhw4wU/Bp+GUs4hqAJdm8C5dM/e8TE/OkzF8frMvRZO
AyCgKpE61TO2dPfQ6JCrBlXPgIELXN1PFJKHatGBPgzy
C02NCszJiSEE2vB44TymiGN2pAz0eUaZPUr8z5U= )
4oj9jsupshjq974ju9ojat1n4f89b6eq.netagent.example. 0 [折返し]
IN NSEC3 1 0 1 1290 4OJ9JSUPSHJQ974JU9OJAT1N4F89B6ES A RRSIG
4oj9jsupshjq974ju9ojat1n4f89b6eq.netagent.example. 0 [折返し]
IN RRSIG NSEC3 7 3 0 20101217071342 (
20101119071342 10970 netagent.example.
U3f/cjjOHqswTClgxVyOkKugpGwNHYGnFCR3i10mHHjj
kH9QVVTp/5lJZhPABOkhMByk1lO1xZMZo9Va5LA3oEGD
hc2lmRNUtU/1eEjFL9mEH3Ig55U6TH0WauTivyxCQfYv
EcdTWaE7O6znudNHhYGGowvSm2jMD3C0w0g+MTo= )
oj4tc3knsrbm09idouc2872s5u50jplu.netagent.example. 0 [折返し]
IN NSEC3 1 0 1 1290 OJ4TC3KNSRBM09IDOUC2872S5U50JPLV [折返し]
RESERVED0 A NS CNAME SOA NULL WKS PTR HINFO MX TXT AAAA [折返し]
LOC SRV NAPTR CERT DS SSHFP IPSECKEY RRSIG NSEC DNSKEY [折返し]
DHCID NSEC3 NSEC3PARAM SPF
oj4tc3knsrbm09idouc2872s5u50jplu.netagent.example. [折返し]
0 IN RRSIG NSEC3 7 3 0 20101217071342 (
20101119071342 10970 netagent.example.
Uz9CdmXwfpXw0gumfl/Q2+jL7EQ2oA55sG0e2R/doYeH
tkuJvPauyPfharlsEBfeREBIvVdU87PTeb7T5Foo8Qf/
LG3TLYQIXPQtw3lX2FM2SLEGRiQ5pClwADROCs/c4KcM
vK1q1pAeDeKHwt8Ii5Lc98NfZHkLab6+QXeI6gg= )
0udor1jnobkp2u1olrmj3ot86aejv62c.netagent.example. 0 [折返し]
IN NSEC3 1 0 1 1290 0UDOR1JNOBKP2U1OLRMJ3OT86AEJV62E A RRSIG
0udor1jnobkp2u1olrmj3ot86aejv62c.netagent.example. 0 [折返し]
IN RRSIG NSEC3 7 3 0 20101217071342 (
20101119071342 10970 netagent.example.
vDszM6GVvRK3eqUMJZ3L81U9jt0ZlyHi9Mh43gZIS2Cz
c+IQMKFHdjyo2dFT5sCIyaLWpOK09qm+roEiwg8ZNfdk
hMPxqR+gmd4yxuTXuNe22JFo1dKXO88U1ykotA6MokC9
cjdRjmBeOASzsyFgx71vJoOE/X7hdEq48lunX9I= )

;; Query time: 5 msec
;; SERVER: 127.0.0.1#10053(127.0.0.1)
;; WHEN: Fri Nov 19 16:13:42 2010
;; MSG SIZE rcvd: 1318

 DNSSEC の署名確認をします。phreebird が生成するDS RRを上位ドメインのサーバに登録してもらう必要がありますが、本稿ではトラストアンカーとしてリゾルバに設定します。まず、DS レコードを取得します。

dig +nocmd +noquestion +nostats +norec +dnssec [折返し]
-p 10053 @localhost netagent.example ds
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33236
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
netagent.example. 3600 IN DS 10970 7 1 [折返し]
4CEA2D546BA9100B59FFBA3683FFCF3B9AE0FCB0

netagent.example. 3600 IN RRSIG DS 7 2 3600 [折返し]
20101217073730 20101119073730 10970 netagent.example. [折返し]
u0xLahDWHEuLvvvBEtYfnE/kQgcL1HTLUgK9uLM67CGbSJt7Dc9p8NTp[折返し]
Ejza0etHJLPNpUqDMkhL0N2BEU9b2DPL8Z/pONP8/e8Kjj1uP31x+gp3[折返し]
v+G9omBQ8uL0BMT/s506a8SfPq5BK/kFJMNO7MBl01rzlO4pNQk5Gc1O dSo=

 今回はリゾルバに unbound を使ったので、unbond.conf を変更します。

$ diff unbound.conf.sample unbound.conf
40a41
> interface: 0.0.0.0
296a298
> do-not-query-localhost: no
314c316
< # auto-trust-anchor-file: [折返し]
"/usr/local/etc/unbound/root.key"
---
> auto-trust-anchor-file: [折返し]
"/usr/local/etc/unbound/root.key"
332a335
> trust-anchor: "netagent.example. 3600 IN DS [折返し]
10970 7 1 4CEA2D546BA9100B59FFBA3683FFCF3B9AE0FCB0
"
498a502,505
>
> stub-zone:
> name: "netagent.example"
> stub-addr: 127.0.0.1@10053

 これで、自前ゾーンもDNSSECに(なんとなく)対応できました。

dig +nocmd +noquestion +multiline +dnssec [折返し]
@localhost netagent.example ns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, [折返し]
status: NOERROR, id: 20876
;; flags: qr rd ra ad; QUERY: 1, [折返し]
ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
netagent.example. 86385 IN NS ns.netagent.example.
netagent.example. 86385 IN RRSIG NS 7 2 86400 20101217090304 (
20101119090304 10970 netagent.example.
SbZ/YFhPJwlz2Bnz/Zc1tS1YQjQZc8z5ktgrXRuAHW66
Sxn/3wRLc+0b3GcJA7/E1rSQJqOj2b1mgGvDroWScwj0
aB1khnxWfrJqbkDa2vzvr9TOXRI6tQKKI7aSfLBjjX+W
CXDYnZ5uPtq/4FO3l31eG2MDSYnWt3/oB2mUyGQ= )

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 19 18:03:19 2010
;; MSG SIZE rcvd: 238

 プロキシとして署名をその場で付加することで、DNSSEC の導入は容易になるでしょう。RR不存在を示すNSEC3 RRはその都度生成され、実際の実在レコードとは関係ない名前を使いますが、これも実用上問題ないという割り切りかと思われます。
 DNSSEC プロキシとしての phreebird コマンドは、コンセプト提示用に最低限の実装しかなされておらず、署名済のドメインにも署名を付加したり、NSEC3 のハッシュが SHA1 だったり、レコードの存在するドメイン名に対する存在しないRRTYPEについての問合せへの応答がおかしかったり、NSEC3PARAM のような DNSSEC 特有の RR を返さなかったりします。既知の問題点や今後の展開については、アーカイブに付属の README.txt や HACKING.txt に書かれています。
 最後に Phreebird Suite の他のコマンドも簡単に紹介します。

-phreeload
 phreeload は LD_PRELOAD を使って OpenSSL の X509_validate_cert() を乗っ取り、DNSSEC でドメイン名が正しければ OK とします。

-unbound_trace
 unbound_trace は、DNSSEC チェックをします。unbound-host と比べてとくに利点があるというわけではなさそうです。

-ldns_chase
 ldns_chase は DNSSEC を上位ドメインまでさかのぼって確認し、ツリー表示します。dig +sigchase に比べて表示がコンパクトです。手許の環境では頻繁に bus error で異常終了しましたが…。

-phreeshell
 phreeshell は、OpenSSH の ssh(1) にパッチをあてたもので、DNS経由で認証を行なう拡張がなされています。Black Hat の発表スライドの6枚目から紹介されているものです。

-ldns-hvc
 ldns-hvc は、DNS トラフィックを http トンネルに通す拡張がなされています。具体的には、問合せ先のホストに対して、http://_host_name_/.well-known/dns-http?v=1&q=_query_ 形式で、_query_ 部分に、DNS 問合せパケットを BASE64 変換したものを渡します。phreebird コマンドはこの機能のデモのために 80 番ポートを listen します。

 実際に運用してみなければ本当のところは判断できませんが、これらのツール群で示されたように、DNSSEC によって組織間の認証が行えるようになるとすると、それは悪いものではないように思えます。

最近のDNSSECの動向

 こんにちは、ネットエージェント株式会社研究開発部、大阪支社の山口です。今回は、DNS のキートピックのひとつである DNSSEC(DNS Security Extension) について紹介したいと思います。

-----

 DNS(Domain Name System) とは、ご存じの通り、インターネット上に展開されている階層的な分散型データベースのことで、主にホスト名とIPアドレスの対応付け等に使用されています。現在のインターネットにおいては DNS はもはや必要不可欠なシステムであり、インターネット技術の根幹といっても過言ではありません。しかし、にも関わらず問題のある設定の DNS サーバが修正されないままサービスを継続している場合も多く、DNSはセキュリティ的な問題点を指摘されやすいサービスのひとつとも言えます。
 そんな中で注目され始めた DNSSEC ですが、つい一昨日の2010年10月17日に、jp ゾーンに公開鍵情報である DNSKEY RR が追加され、jp ゾーンへの署名が開始されました。DiG コマンドで確認してみると、DNSKEY RR と RRSIG RR がセットになって返ってくることが確認できます。

$ dig jp. dnskey +dnssec +multiline

; <<>> DiG 9.7.1-P2 <<>> jp. dnskey +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42388
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;jp. IN DNSKEY

;; ANSWER SECTION:
jp. 84802 IN DNSKEY 256 3 8 (
AwEAAbYhrQMQH9ItfsO/SFNAFVwpV669OF9+FGtEe5IO
TuajY871KONNqqyojToAiyQSTmhibS7q1zaNNx4cZlQw
l/PvF4yVwYU51OYPs5SsMntZlWTkebDpTbfyVzPkKZ2b
rrS/+6QOmxB5IpqzdbdLc/mjH6UWVWOgrG+CBSmD9PoX
) ; key id = 39186
jp. 84802 IN DNSKEY 256 3 8 (
AwEAAcxWIhw/wv6vwbOKO+umDTP+cPMkoRykho4kLycc
g6MB8XkXMThBNd1GXEolvzuyd/RAjGJqo2mdzxLyq3T5
4NTE9iIezmFhM00LWNLFH8rSzhx0PyIid3GJT/SQnH4w
qdaYZ3gVEzGfriWFWP3u2LqntGjdTr9+rdAf0V+ekrEj
) ; key id = 58308
jp. 84802 IN DNSKEY 257 3 8 (
AwEAAbPUX+Fy7ONuMs8+HY77DX/qaI2ZCaGUNJRKDxdv
k2XiecvXNu8upgjg9B9UH6fP6TRxE3NQ6iP3DeHkNSQC
FeWa7ItBxY0gQyPZPJATzIc/lWPcjWAwMOYUI/Un0KSq
93suzUhS5sDjW6O7FWfURLYeAhg4zvDHEksCG0wULldI
7qQENO/zKhtz1MpNDHjZrMdSbfPgCseodrfsgOlD+Br5
Nz97mSXg5RbYYhEJ9+yWcUA9YT/sYMNr7JRRzd71UIII
bvo5Th+YM+f34s+O0JTqwOyvNmehlRElvyTyicvk6db8
0PLTslWLHSNrUkI06Yo9JyHuitcQKumIGnA8tO8=
) ; key id = 1369
jp. 84802 IN RRSIG DNSKEY 8 1 86400 20101116044500 (
20101017044500 58308 jp.
MBS36a1Uicbj/DjsEHe8wFKrnkGz6cdawvbgO3AKvPNy
h7bz6q1+NgUTHnjlPppIexQPymR/8GKQuZE+kgQM0Pen
XJ1n6IqJ+jCJHjuGSRXBYCwfJ8mGhFqS3iYRuQKV3uf4
dGubI4/6ETN/WBWAvchPJyTn4vnivO12ZZCElc0= )
jp. 84802 IN RRSIG DNSKEY 8 1 86400 20101204082432 (
20101004082432 1369 jp.
onmVsz3gbgEhYsjyVB0AhS0pNayOZXGwftUjKNC8Ap2Z
xyg/YANWi3RxbgIP20KfZohVPPqXTWlNXVt56pR2ldcI
w8PhTt8JzB1E5pUveeg5o/cXkxsaTZdCk1yztLTn+qp/
dxCPCP/sqqB7XGO9L3/sViL3SB0AGSUF1R8etb/hRqVT
grx4ud3tElom3VtmxU9Aph8+T55hG6lWue/GN+Ku37Vq
ovmjBeJy5RVlJ6UFRI+LqtevL2ZhSMCiTe5z6DS3j07b
9+6FUtgw4U2dw7Z/G5HFUe6fz0WrNqgKrqBwqIR9YHgT
09S8REkHQOy2f3KR161cQ334k5lWNiK6zA== )

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 19 00:11:15 2010
;; MSG SIZE rcvd: 1055

 JP ゾーンの署名に先行して、今年7月から root zone に署名されるようになっているので DNSSEC の簡単な確認手順を紹介します(参照)。確認には、ISC BIND 9.7.1-P2 付属のツールを使用しています。

 まず root zone の DNSKEY を取得します。

$ dig +nocmd +nocomments +noquestion +nostats -t dnskey . > trusted-key.key

 取得した DNSKEY から、DS を得ます。DS は KSK のハッシュです。

$ dnssec-dsfromkey -2 -f trusted-key.key .
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A160
7371607A1A41855200FD2CE1CDDE32 F24E8FB5

 この値を root-anchors.xml の値と比較します。root-anchors.xml の真正性は同じディレクトリにある root-anchors.asc(OpenPGP 署名) もしくは root-anchors.p7s(S/MIME 署名) で確認します。OpenPGP 署名の確認は GnuPG を使います。dnssec@iana.org で登録されている公開鍵を手近な鍵サーバから取得(あるいは icann.pgp をインポート)し、確認します。

$ gpg2 --search-key dnssec@iana.org
Warning: using insecure memory!
gpg: searching for "dnssec@iana.org" from hkp server pgp.nic.ad.jp
(1) DNSSEC Manager <dnssec@iana.org>
1024 bit DSA key 0F6C91D2, created: 2007-12-01
Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key 0F6C91D2 from hkp server pgp.nic.ad.jp
gpg: key 0F6C91D2: "DNSSEC Manager <dnssec@iana.org>" not changed
gpg: Total number processed: 1
gpg: imported: 1

$ gpg2 --verify root-anchors.asc root-anchors.xml
Warning: using insecure memory!
gpg: Signature made Tue Jul 6 22:49:10 2010 UTC using DSA key ID 0F6C91D2
gpg: Good signature from "DNSSEC Manager <dnssec@iana.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2

 S/MIME 署名の確認に GnuPG 2.0 以降に付属する gpgsm が利用できます。本稿を書いている時点では ICANN Root CA 証明書の安全な入手方法や、CRL の取得手段について十分調べられていないので以下の手順については参考程度にしてください。
 何らかのかたちで ICANN Root CA の証明書が正しいものであると確認できたとして、icannbundle.pem を gpgsm で取り込み、trustlist に fingerprint を登録したのち、CRL チェックを無効にして verify を実行します。

$ gpgsm --disable-crl-checks --verify root-anchors.p7s root-anchors.xml
Warning: using insecure memory!
gpgsm: Signature made 2010-07-15 01:39:36 using certificate ID 0x4A45F57D
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: Good signature from
"/CN=dnssec@iana.org/O=ICANN/EMail=dnssec@iana.org"

 確認の済んだ root zone の DNSKEY を検証に使うリゾルバに登録します(ISC BIND の場合: Using the root DNSSEC key in BIND 9 resolvers、Unbound の場合: Unbound: Howto enable DNSSEC)。
 信頼済キーとして root zone の DNSKEY が設定されているリゾルバに問い合わせると、DNSSEC の鍵確認ができた応答には ad フラグが確認できます。

$ dig . ns +dnssec +multiline

; <<>> DiG 9.7.1-P2 <<>> . ns +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40247
;; flags: qr rd ra ad; QUERY: 1,
ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 518352 IN NS h.root-servers.net.
. 518352 IN NS e.root-servers.net.
. 518352 IN NS m.root-servers.net.
. 518352 IN NS g.root-servers.net.
. 518352 IN NS c.root-servers.net.
. 518352 IN NS f.root-servers.net.
. 518352 IN NS b.root-servers.net.
. 518352 IN NS j.root-servers.net.
. 518352 IN NS a.root-servers.net.
. 518352 IN NS k.root-servers.net.
. 518352 IN NS i.root-servers.net.
. 518352 IN NS l.root-servers.net.
. 518352 IN NS d.root-servers.net.
. 518352 IN RRSIG NS 8 0 518400 20101025000000 (
20101017230000 40288 .
c1GnhfkgNadxcM42TBbWKj3kqu54UAyDQ1KJ+lPIzx25
AXlcqFk+A5Kw1ik8qAL2xKo8hSqruX07m3SZqMlyC7h5
iF+7K/F/oi4GTnEOOv/Bf0Qd1GgmDWTIw8TWKKBL4jJ5
0FYkOoeEUVm1FrrqMXjNAe9pzM6W1LJs7s6Iyig= )

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 18 23:42:22 2010
;; MSG SIZE rcvd: 397

 DiG コマンドの sigchase オプションを使うと、DNSSEC の信頼の連鎖をたどって検証する際の問い合わせが可視化されます。

$ dig www.icann.org. +multiline +sigchase +trusted-key=./trusted-key.key
;; RRset to chase:
www.icann.org. 330 IN A 192.0.32.7


;; RRSIG of the RRset to chase:
www.icann.org. 330 IN RRSIG A 7 3 600 20101025205718 (
20101018132532 32873 icann.org.
NBCCesXXfcX3IFQiGcEEaLXQH+aINj0/Xmi07kVFPooV
Vq6jJfxhu0k5MibbqQEnTZEvSWnrD8RjOTfU71A/mvjA
ZpdAu4RkTwh8JTd55e7fIwAn08aDsqGoSvYOfG7ScWdI
ck7oV8b1c7Y2/UWUPxsLmL0YfOh7TE0fuj7zenY= )

Launch a query to find a RRset of type DNSKEY for zone: icann.org.

;; DNSKEYset that signs the RRset to chase:
icann.org. 2366 IN DNSKEY 256 3 7 (
AwEAAaP7xhH7Sp6HR9xxs2pExt4TImO1qG6BGC3s1q6u
ErTyPXAbz5ViDV3WmFwkWhcR6BirBQ+BdCoRy5TwnfNU
wmbO4dfkH4SPjN2ykGERKOxa5tghOIHe1DrysI1CDZXB
TZgHx7pn+Uzz1zWy0Kyg2HEYyM8weEPPkrxf08cdydfj
) ; key id = 7008
2366 IN DNSKEY 256 3 7 (
AwEAAbJ41qqdVirOiibZRb11GeSX6lS9IS6dmINHS4CI
a9kiIGlkrtfOyLTY/xWj5iPKKSM9fy/1Xni7MbbZ5HL5
IPC3HC5DWh9EdPT9O593nEn7osX5xGKwXsFcOPRtQEbZ
isvQr4Y5OL7gGPtj8z9F6myTz9GWONmNYroCIBUsOxJT
) ; key id = 32873
2366 IN DNSKEY 257 3 7 (
AwEAAZuSdr4KSy77Mm3uQ6++HZBP9yZuDXEb41z9PZV5
UdLuTjyOH13Ip7lXXia5ijme3shsmdm5JDQaKtO6DWdD
m73QPObEYaYjGjA75j6wMEM0Eb+Oy8Kp7TEjC7o5B8TY
JJiqOcNaCNmJedNfgepqss4mWaW15B+OJQxJqmmZVY16
M4WEZSmXvMEf93i0OzbHY3BHrXi3qZxPzrBs6RK3s0NS
dAUnCOSx/E+vBNnF/UMvk29YxUZbfL11LlfLbCtKTxiG
nFnX8dTeNfldBKPcNrq+iqxQpihfxiKUrJ7f8DyhjtLj
hp0CKRyCpd49BgZpR9pRNRL8ZqU4by5PjFnNXA0=
) ; key id = 7455
2366 IN DNSKEY 257 3 7 (
AwEAAcyguBHFC9GiUguPfH8zmaCNfhUBHWUQ1EluPttD
Wt12+9AfavAGTitXRno1BGcsUqkZHf/NA/oTL8kNr5Lr
IUvBF70c6vvXipSgsUlY48sLqWYUfXbv2WDJdBQeUEmb
Uz0S2e8hvTDMegqLTv9PHqjEfrdnNs8b+8DTu+Vmw9f4
RhGP2In7Gvo6rCbRQGVF/iASJ4skhHKnIRf2FiFjgrTk
fgN8jZLBW5nKwhivEj8aUie6eYNgJioUklx/E0z7y7h5
ZYQragNHVwpPvu66B4UDyYrTU66YiuvP3wS3SqPAl9JK
SlLcV0uVO+eZM9QMlWg1eQhJ35HOJnqXcoCzE/k=
) ; key id = 41643

;; RRSIG of the DNSKEYset that signs the RRset to chase:
icann.org. 2366 IN RRSIG DNSKEY 7 2 3600 20101025234318 (
20101018132532 41643 icann.org.
jF6hzh7d+XKmeHaYOwtM9ROTY1eemWPXC5knqn0Rk6lC
yIVmhNdXoNJaYYh/xoyNIpPWKxOID6royjL+a81Xcidu
BGF+J0Q+aX9K3xz8ytv0RW7jTQrS4Y1cYdC1phDeAruq
PdCOCVxkCItrM5bk2x3bxZE5IsZN2zWV0abZyhBSfAS2
gP2St5Im/+nOYalZKU2iVRfeNtJeJY7EntXFUaEWl3as
qgwNDZcP9YROVYrcG7qp5APB2gU1n/hdfcPQ4n4bhYOZ
ynSR1cLhbpYAOxc3eVgvqzNdx3cflMPRdxSpZqa60Mgy
H2pHCyeie2R6x7MHccFS6u8FXUlAtJ9Otw== )

Launch a query to find a RRset of type DS for zone: icann.org.

;; DSset of the DNSKEYset
icann.org. 85166 IN DS 41643 7 2 (
B8AB67D895E62087F0C5FC5A1A941C67A18E4B096F6C
622AEFAE30DD7B1EA199 )
85166 IN DS 41643 7 1 (
93358DB22E956A451EB5AE8D2EC39526CA6A87B9 )

;; RRSIG of the DSset of the DNSKEYset
icann.org. 85166 IN RRSIG DS 7 2 86400 20101031154652 (
20101017144652 245 org.
gce3F2zwVLxPkaqfCWCD94mVLqbK5JeuqGMoJPf+sSJj
KWfv7SwvDwgdJTkC8Lhi+R1heAaZn0CSzK+y7jG5JBVB
lp9K+GxkPA3kI1jbDdy4PE0VkNMPC90odEmQ82XeWa+b
4etWv447Eh9AEGQfpaKMnQB69MvMV+Vy4tprkTI= )

;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING A RRset for www.icann.org. with DNSKEY:32873: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Now, we are going to validate this DNSKEY by the DS
;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for icann.org. with DNSKEY:41643: success
;; OK this DNSKEY (validated by the DS) validates
;; the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
;; Now, we want to validate the DS : recursive call

Launch a query to find a RRset of type DNSKEY for zone: org.

<中略>

Launch a query to find a RRset of type DS for zone: .
;; NO ANSWERS: no more

;; WARNING There is no DS for the zone: .

;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for org. with DNSKEY:40288: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Ok, find a Trusted Key in the DNSKEY RRset: 40288
;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success

;; Ok this DNSKEY is a Trusted Key,
;; DNSSEC validation is ok: SUCCESS


 DNSSEC の連鎖の確認は、Unbound に付属の unbound-host コマンドでも可能です。

$ unbound-host -v -f ./trusted-key.key www.icann.org.
www.icann.org. has address 192.0.32.7 (secure)
www.icann.org. has IPv6 address 2620:0:2d0:200::7 (secure)
www.icann.org. has no mail handler record (secure)

 以上の手順で、今年7月に root zone に登録された鍵情報から DNSSEC の確認ができることが分かりました。さて、はじめに触れた jp zone ですが、ルートサーバに DS RR が登録されていないので、上記の設定では署名の確認ができません。上位サーバへの DS RR 登録のスケジュールは公表されていませんが、しばらく様子を見て年内をめどに行うというような話が聞こえてきています。ちなみに「JPドメインサービス名への導入」は2011年1月16日であると発表されています(参照:JPドメイン名サービスへのDNSSECの導入予定について)。

 自サイトへの導入をどうするか、という点についても少し考えてみます。リゾルバの場合ソフトウェアのバージョンアップで自動的に対応することになるケースが多いので、そういった折に計算機資源やネットワーク帯域について確認をしていくのが肝心でしょう。コンテンツについては、鍵の交換手順などの多くがいまだ手作業に頼っているようなのでツールの整備を俟ってローカルネットワークのテストサイトなどでシミュレーションをしつつ時期をうかがうのがよいかと考えます。
 DNSSEC については、電子署名技術を用いて改竄の検知や RR の実在確認などができるというメリットが謳われています。その一方「amplification attack(大量パケットを対象サイトに送りつける攻撃)に使われるのではないか」、または「署名計算に計算機資源が膨大に消費されるのではないか」といった懸念も聞かれます。
 DNSSEC の問題点は、イリノイ大学シカゴ校の Bernstein 氏の1年ほど前のプレゼンテーション「Breaking DNSSEC」が的確に指摘しています。RR の不存在確認に使う NSEC3 RR の crack に 9台の PC を使えば1日に5兆8千億通りぐらいの計算が可能だという実績から、GPGPU を使えば同等量の計算を1台でできるのではないかという見積りなども示されています。ちなみに、資料中で *.com で DNSSEC 設定のあるドメインが2009年8月時点で274サイトだったと書かれていますが、同じ方法で先週数えてみた結果 *.com で2707サイトありました。.com に着目すると約1年でおよそ10倍になっているようです。

 DNSSEC はまだ普及段階であり、今後どのような発展を遂げるか分かりません。仕様上の問題、現行の実装上の問題等、実際にやってみなければ明確でないことなどもあり、伝聞情報だけを頼りに結論を出すことはできません。しかし、徐々に DNSSEC が普及し始めているのは事実であり、今後の動向も気になります。
 また何かありましたらこのブログで書きたいと思います。

ドメイン名レピュテーション

 みなさんはじめまして、ネットエージェント株式会社、研究開発部の山口尋久(やまぐちひろひさ)と申します。大阪で製品やサービスの開発をしています。
 今回はドメイン名レピュテーションの扱いについての最近の話題を紹介したいと思います。

-----

 「レピュテーション(Reputation)」とは、通信を制御/ブロックするためのデータをユーザから収集した評価情報をもとに整備する手法のことで、近年では迷惑メール対策によく使われます。レピュテーションを直訳すると「評判」という意味であり、これはいわばユーザからの「タレコミ」と言えます。このような情報提供により、実績報告に基づくデータベースの構築がより早期に可能になり、仮に通信するべきでない問題サイト(マルウェア配布サイトなど)が新たに見つかった場合も、この即応性によりすぐに対応可能となります。
 ただ、この早期対応可能であるという特徴は、悪意を持った報告や誤った報告に対して脆弱な側面もあります。迷惑メール送信実績サイトを集めたブラックリストの中には、この即応性を重視しすぎた結果、大手ISPを丸ごと登録してしまい、なかなか解除されなかったといったトラブルを経験したという話もしばしば聞かれたものです。
 確かに、評価情報を収集する際「迷惑メールを送信した」というネガティブな情報は比較的集めやすいですが、逆に「問題がない」という情報は扱いにくい(集めにくい)印象があります。
 よって、DNSサーバやメールサーバなど、問題のある設定をしてしまいやすいサービスについては、設定状況を確認してポジティブな評価をしていくというのも有効な方法かもしれません。また、どれぐらいの期間それらの情報が有効であるとするかでデータベースの特徴も変わってきます。

 評価情報データベースの実装自体は、key-value型のデータベースを使えば容易に可能なので、レピュテーションに関しては、情報収集の手段(いかにして情報を集めるか?)が各公開リストの大きな特徴(差別化される点)と言えます。迷惑メールの送信実績のあるIPアドレスを収集したもの、そのアドレスを含む同一契約と思しきアドレスブロック単位で提供するもの、ドメイン名単位で収拾するもの、フィッシング(phishing)サイトを収拾したもの、マルウェア配布サイトを収集したものなどは、あちこちで公開されているサーバやアプリケーションの設定サンプルによく含まれています。
 とはいえ多数ある「レピュテーションエンジン」を切替えて使う手法は、色々なサイトで試みられているものの横断的な利用についての議論はあまり多くはなかったように感じます。
 そんな中、今年の8月にIETFのDKIM(DomainKeys Identified Mail)WGの議論からスピンアウトする形でnon-working groupメーリングリストが作られました。non-working groupメーリングリストでは、DKIMに特化した話ではなくすべてのアプリケーションに共通する形でドメイン名のレピュテーションの扱いについて議論されていくようであり、メーリングリスト内では、データベースの用途について考慮すべきか、古いデータをどうするか、提供された評価情報をどのように扱うか、複数データベース間での連携をどうするかなどの、メンテナンスにまつわる諸問題、問合せ記録を見ることによって問合せ側のサイトのプライバシーが明るみに出る可能性をどのように解決するかなど、周辺の諸々の事項についても様々な意見が出されています。個々の議論については、アーカイブが公開されているので、興味のある方は追いかけてみてください。
 個人的に、特に興味深かった話題としては、ドメインレピュテーションリストの用途(メール用かurl用か)について議論すべきであるかという話の流れの中で、「通信の中身(私信なのか取引上の連絡なのか等々)に比べたら、サービスの種別(メールかWebか)はさほど重要ではない」という趣旨の発言がありました。spam送信サイトのリスト、フィッシングサイトのリスト、マルウェア配布サイトのリストといった用途別のリストばかりが念頭にあったので、この視点は新鮮に映りました。
 通信内容の性格を考えると、たとえば私的な通信の場合は個人的なつながりによる関係性により重みづけがきまるためレピュテーションによる評価づけがふさわしくないでしょうし、逆に不特定多数へ送信される広告などはレピュテーションによる評価づけが有用だと言えるでしょう。また、メールアドレスのドメインとwebサイトのドメインが同じである場合にそれらの評価情報に関連性が認められる場合も多いでしょう。用途別のサービス横断的なレピュテーションデータベースが作られるとすれば、どのようなものになるかどのように使いこなしていくのがいいかと想像が広がります。

 レピュテーションという手法は古くからあり、既存の実装も多数存在する中で、こういった議論を経ることで新しい実装のあり方や活用の仕方が見えてくるとまた面白いかもしれません。
記事検索
月別アーカイブ
QRコード
QRコード