----------------------------------------------------------------------
BoF名 日本DNSオペレーターズグループ BoF
BoF開催団体名 日本DNSオペレーターズグループ
開催日時 2009年09月04日 18:00〜20:00
参加者数(※) 約110名
----------------------------------------------------------------------
Agenda
1. DNSOPS.JP Update (石田さん@DNSOPS)
2. DNSSECの導入に向けて (白井さん@JPRS)
3. いますぐDNSSECで遊ぶには (藤原さん@JPRS)
4. ANYでアップデート (民田さん@JPRS)
5. chrome prefetch (吉村さん@OCN)
6. lightning talk
a. AAAA for A
b. DNSSECとDNSOPS.JP
----------------------------------------------------------------------
------------------------------------------------
1. DNSOPS.JP Update (石田さん@DNSOPS)
------------------------------------------------
MLの登録数・投稿数の推移紹介
本日のアジェンダ説明
----------------------------------------------
2. DNSSECの導入に向けて (白井さん@JPRS)
----------------------------------------------
root, TLDがdnssec導入するといっているのでいろいろ検証
iana, isc が検証用DNSサーバを使えます
packet sizeもいろいろ問題になりMLで流れたケースもそう
大規模ゾーンとか署名すると？
-> マルチスレッドがとても有効。おすすめ。
上位と下位を紐付けする鍵の更新はしっかりと。
-> DSは上から下へさすのみ。NSは上下に同じもの入れる。
いままでと少し違うレコード。
ルートが変われば下もいじらないといけない
-> bind 9.7 から自動更新の仕組みが入っている。
これないと運用者側はけっこうきついと思う
dnssec対応すすむと、する気ない人も影響でます。
-> インターオペレラビリティが重要
::質疑は藤原さん発表後まとめて::
----------------------------------------------
3. いますぐDNSSECで遊ぶには (藤原さん@JPRS)
----------------------------------------------
いますぐ遊びたい人向け
-> DLV
DLV ?
rfc4431, rfc5074 dnssec look a side validation
ISC DLV
dlv登録サービスやってます。だれでも遊べます。
example.jp.dlv.isc.org が登録され、検証まで
クエリがたくさんでます。
bind9.7だと設定簡単。9.6は10行ぐらいいろいろ。
dnssec-keygen そのまま使うとややこいのでちょっと大変
-> dnssec.sh ってのを作った。少し簡単になります。
web で公開してます。
zone ファイルもいじります。key は include にしとくと
かぎ更新が楽です。
dnssec.sh は鍵やらsoa serialやらreloadやらまとめて
やります。
dlvにtxt rrで認証コード書く必要もあります。
see also
http://member.wide.ad.jp/~fujiwara/dnssec/
q. 鍵を失効してfailするという実験はやった？
a. no
q. 9.7 の validation fail したときどうなるの？
a. servfail
c. こわーい
c. soa serial unix time でつけるのって
2009090901 だったんだけど、unix time にしたら
値が小さくなったことあります。みなさん気をつけましょう
q. 9つの手順がスライドにあったけど、本物のdnssecがきたら
いらなくなるのは最後の手順のdlvをiscに登録するのだけ？
a. yes
q. zone 更新したら何をしないといけない？
a. 7.のdnssec.sh [zone] を実行すればよい
c. かぎを更新するときはレジストラ・レジストリに登録・
jp dnsに反映させる必要もある。
c. みなさん時計は正確に合わせてください。dnssec時は
検証に失敗するので、しっかりとね。
石田@dnsops代表幹事さんからお話
-> インターオペラビリティを関係者あつめてやるとかを
後ほどライトニングトークで。
----------------------------------------------
4. ANYでアップデート (民田さん@JPRS)
----------------------------------------------
それはなぜか7月にやってくる
脆弱性のまとめ
- bind9 all version, remote exploit, workaroud none
- slave zone only ならもんだいなし、masterあるとだめ
- bind9 組み込みゾーンも問題なし
攻撃試してみよう
- 簡単におちる。自分で使いやすく改造してみた。bindコロリ
それでは実演
- 127.in-addr.arpa , localhost zone がある。
% bind-collori @127.0.0.1 1.0.0.0.127.in-addr.arpa
-> ころり。
標準コマンドであるnsupdateでもできる？
type any が送信できないのでだめでした
master が落とされても、slaveのおかげで気づかないのでは？
-> soa expire を jp.zone つかって調べてみた
-> 1week ぐらい？ほんと？
計測してみた
1week : about 40%
42days: about 20%
10sec というのがいた。男前。
workaround none ってなんで？
bind9 aclきかない。
-> update って acl かけられるよね?
source codeみると
-> ようは、acl check よりも前に該当コードにひっかかって落ちちゃう
-> source の commnet にこうかいてあった
「僕も変だと思うんだけどrfc2136に書いてあるんだもん」
--> いや〜BIND9ってRFCにきわめて忠実ですね（棒読み）
q. 普通レジストリとか早めに情報がくるんじゃないの？
a. こんかいはこなかった。どこぞの誰かがbug reportとattack code
をいきなり公開した。
c. 検証コードが10行ぐらいだから簡単すぎて危険
c. rfc author は paul vixie
q. bindコロリは引数与えられるようにしただけ？
a. yes
c. severarity は high だったんだけど、セキュリティ組織では
midium になってた。(dosだから?)
それで対応が遅れたのもあるんじゃないかなぁ
c. install だけして攻撃を待つという対応もある。
q. rfc の中にはなぜそう書いてあったのか理由も書いてたりする？
a. わからない。10年以上前のRFC。
-------------------------------------------
5. chrome dns prefetch (吉村さん@OCN)
-------------------------------------------
web page の link 先の FQDN をあらかじめ名前解決する
-> 大量のクエリが
chrome でやってみた
www.ocn.ne.jp (4 query) prefetch no
www.ocn.ne.jp (47query) prefetch yes
firefox でもある。
www.ocn.ne.jp (5 query) prefetch no
www.ocn.ne.jp (59query) prefetch yes
google で検索するだけで大量にでる。
さらにchromeで実験。
www.ocn.ac と打った時点でクエリ送信される
www.ocn.aa だと出ない。
--> www.ocn.a[a-z] してみた。ccTLDが存在しない場合は送らない。
www.ntt.co.jp と打つ途中(www.ntt.co)でクエリでる
--> firefox ではおこらない
キャッシュサーバ大変
クエリふえる
1 ip addressでquery制限していると影響でる
web browser share ??
IE 67%
FF 30%
etc
--> IE8 は prefetch なし。対応したら大変なことに。
q. 検索にいくのはcctldだけ？
a. 確かめてないけどgtldもひくと思う
c. tld自由化されるとどうなるかしら。よりたくさんドメインがある
TLDが優先されたり、たくさんクエリでたりするのかしら
c. 製品開発している人いる？
c. はいいます。80:20 の法則じゃないけど、よく使われる
ドメイン名を中心にアプリやら実装したくなっちゃいます。
c. ブラウザの表示が速くなることに興味があるひとは、他の
要素で遅くなることをおさえたいのかなぁ。マウスが近づいたら
クエリ出すとかいろいろ改善してほしいなぁ。
c. DNSはインフラなので難を受ける立場にある。クエリ増えようが
なんだろうが、お客さんが喜んでくれればいいんでしょうねぇ...
c. DNSよりブラウザが早いことのほうが大事だと思う人どのくらいいる？
--> けっこうたくさん挙手あがる
--> そうだよねぇ
c. IE8実装されたら......ってのもあるけどすぐにはあがらないだろうし
時間あるうちに考えないといけないね。
c. ブラウザ改善するならこうしてほしい
--> query rate を下げてもらうとか
q. DNSSEC 対応されると、1packet 2kbyte, 40query とかでると
一人あたり1Mpsとかなんとかえらい量がでちゃう？？？
a. キャッシュがきいたり、順番に帰ってきたりするので
もう少しやさしいのではないかと思っている
c. dnssecってnxdomainでもクエリでるよね。やばくね???
c. ntt.co っていうクエリでるってことは、それを登録しちゃうと
悪いことできたりするのかなぁ。すぐには思いつかないけど。
c. link をいっぱいはっつけると DoS ができると思う。無邪気なDoS。
c. DNS が負荷かかることは、注目を浴びるチャンスじゃないかな？
性能を競ったりするとかね。昔はnetscapeが4本はってなんじゃこりゃ
っていってた時代もあるし。
q. キャッシュサーバのクエリ数をはかっている人ってどのくらいいる
のかしら？そもそも少ないんじゃね？
a. 某システム開発会社のキャッシュサーバみてたら、みんなIE使わないので
クエリ増えました。12倍ぐらいふえた。
----------------------------
6. lightning talk
----------------------------
-----------------------------------
a. AAAA for A (石田さん@DNSOPS)
-----------------------------------
ipv4 -> ipv6 translator 必要になってくるだろう
NAT-PT
v4v6 translator
v4をv6アドレスにマッピング
DNS-ALGを利用
世の中 http://192.0.0.1/ だらけでアクセスできない(v6から)
NAT-PT+DNS ALGがある場合
v6に変換したv4返す
なんてことを一緒に考えてくれる人募集
q. URL直書きはほんとに多い。googleのキャッシュとか。
v4アドレスをみてv6クエリひくようなクライアントってあるの？
a. そこから取り組まないといけない
c. クライアント出してくれれば対応はいろいろできそう。
web browserならproxyかますとでもいけるかなぁと思う。
c. そういう環境ならそれで解決できると思う。
c. URLにv4あると、16進数とか書いちゃうとかで何かできないかな
c. kernel に translator いれちゃうとか
--------------------------------------
b. DNSSECとDNSOPS.JP (石田さん@DNSOPS)
--------------------------------------
いろいろみんなでやらないといけない。
dnsops.jp として何らかの活動ができないか？
-> 教育・啓発、知識・経験の共有
--> DNSSECに関する何らかの活動を行おうと思っています。
- besteffortで文書かいたり実験したり。どう？
→ "拍手"
-> dnsops.jp bof なりなんらかの別枠もうけようと思う。いかが？
→ "拍手"
みなさん協力お願いします
----
以上