[Top Page]
------------------------------------------------------------------------
Agenda
- イントロ
- レジストリ関係からトピック
- DNSの応答速度を改善する新しいキャッシュシステム
- DDoS攻撃ネタ
- 統計情報ネタ
レジストリ関係からトピック
- 逆引きDNSにおけるlame delegationの改善 by 小山さん @JPNIC
+ 減らす
o JPNIC に登録されたものが lame だったら削除
o 秋ごろから開始
+ 実施対象
o PA アドレス
o 特殊用途用PIアドレス
o 歴史的PIアドレス
o 全て /24 より大きなアドレスブロック
+ lame 判定基準
o UDP による SOA 問い合わせで aa ビットがつかない応答
o 一日一回調査して 15 日連続して lame と判定した場合技術
連絡担当者へメール通知(割り振り、割り当て先)
o 継続の間は週に一回メールを送信
o 30 日経過しても解消しない場合は、該当逆引きゾーンの委任を停止
NS RR 削除, whois に出力
一覧で出すことはしない
o 途中で lame がなくなったらカウンタはリセット
+ 復活
o 停止後に lame じゃなくなった場合は自動的に復活する
o 復活は次回のゾーン生成時(おおよそ翌日)に
+ lame NS RR の割合
o 2007/04 に 8% を切ったくらい(自然現象で)
o この流れで少しずつ減っていくだろうと思う
+ 最後に
o lame は DNS, DNS 依存のサービスに悪影響が出る
o lame になっている JPNIC 管理下のネームサーバへは逆引きの委任を停止
o DNS 設定は見直そう
o whois の連絡者メールアドレスのメンテナンスをお願いします
Some DNSSEC thoughts by Geoff Huston @ APNIC
- the DNS is a miracle
+ BGP は unsecure だが DNS はさらに unsecure
+ 誰が DNS の答えを返しているのか誰も気にしていない
- DNSSEC のモチベーション
+ 正しいことを示す
- DNSSEC の基本
+ 全てにサインを
- zone へのサイン
- DNS の応答
+ DNSKEY RR
+ RRSIG RR
+ NSEC(3) RR
o なにもないとき
- Validation
+ 本物の鍵でサインされたことをどうやって確認するか
+ どのようにサインするか
+ どのように key revoke するか
- 信頼はトリッキー
+ 全てがサインされていればいいが
o 実際は異なる
- 利点
+ 攻撃されにくくなる
+ DNSの信頼性をあげる
- 欠点
+ zone が大きくなる
o zone は 10 倍になる
+ 応答も大きい
+ 運用が煩雑
+ zone マネージメントが難しい
+ どうやってだれがサインされた応答を使うのか?
+ アプリは DNSSEC の答えを使わない
o 今のところ Web ブラウザは DNSSEC の答えを使っていない
- 意見
+ みんながdeployすれば便利
- .seではじまったが
+ ほんとにどれだけサインされているは疑問
+ crazy だが学ぶことも多い
- zone にサインすると膨れあがるが圧縮することはできないか
+ できない
o 鍵長を小さくすればクラックされる
- DNSSECがないと unsecure なので、問題があると思う
+ 他の手段を含めて、簡単にできる方法を模索する必要があるのではないかと思う
- サーバを運用するものからの意見
+ 応答パケットが大きくなる
+ zone が大きいから負荷が上がる
+ amp の温床になる
+ ぜんぜん secure じゃない
- 導入されて root の公開鍵が公開されたら悪いことされるのでは
+ 7 年ぐらいかかるからその間に克服しましょ
- 技術としては完成しているなら盛り上がるようにしないのか
+ 半年ぐらいトライアルしてみるとか
o 盛り上がるようにがんばります
- DNSの応答速度を改善する新しいキャッシュシステム
by 愛甲さん @ ネットエージェント
+ DoS対策が目的
+ BIND の応答速度
o BIND8 で 15000qps 2.6Mbps
o BIND9 で 45000qps 7.8Mbps
+ 80Mbps 投げたら
o DoS が成立してしまう
+ 応答を手助けするシステムを考えたらどうか
o DNS サーバの手前でクエリをキャッシュしてサーバの変わりに応答させる
+ 応答測定
o 今回はコンテンツサーバに対しての実験
o リクエスト 240000qps 17.0Mbps
o レスポンス 34000qps 3.5Mbps -> 190000qps 19.5Mbps になった
+ 課題
o 管理するキャッシュデータが多くなった場合にどれだけの性能低下が見られるか
o 高性能なハードウェアを使った場合はどの程度の速度向上が見られるか
+ どのようなものか
o DNS の応答だけじゃなくて、パケットレベルで結果を保持している
+ DoS 応答としては弱いと思う
o ランダムな名前を投げられた場合は後ろのサーバに
投げられてしまうので弱いと思う
+ キャッシュのヒット率が50%だとしても性能が10倍違う
o 改善が望めるのは 5% の範囲だと思う
o コンテンツサーバと調整を取る必要があると思う
+ 高いパフォーマンスが出た肝はカーネルの中に入れたから?
o だったらカーネルに DNS サーバを実装してみたらどうだろう
+ 同じような話を他で流用できることができるのでは (ntp とか)
o 今後そういう方向に持っていければいいと思っている
- DDoS攻撃ネタ by 森下さん @ JPRS
+ JPRS のブースでしゃべっているネタ
+ DNS Amp 攻撃
o キャッシュサーバを悪用する
o 小さいパケットが大きくなる
o 攻撃力が強い
+ 攻撃
o ある権威 DNS に大きな RR を書く
o Botnet を使って各所のキャッシュサーバが大きな RR を検索させる
o 攻撃対象の IP アドレスを騙って一斉に DNS 検索をさせる
+ 何が問題なのか
o DNS の仕組み・特徴そのものを悪用している
+ 対策
o IPアドレスを騙ったパケットを外部に出させない
Source Address Validation
o 外部からのDNS問い合わせに応答させない
Open resolver を撲滅しよう
+ Open resolver の撲滅のために
o キャッシュと権威を分割
o 権威は不必要な反復検索機能を無効に設定
o キャッシュでは外部からの問い合わせに応答させない
+ まとめ
o 自分のネットワークが攻撃元にならないように
Source Address Validation
o Open Resolver を無くしましょう
+ インターネット全体での取り組み
o Interop / Internet Week 等
o APNIC / RIPE Meeting 等
o JANOG / NANOG / OARC 等
+ 2ndary を上部の ISP に任せているが Open relay に
なっているが対応してくれない
o みんなで布教してほしい
o JPCERT/CC を介して ISP にお願いしてみるように相談してみましょう
+ BIND が Open Resolver がデフォルトでできないように働きかけてみては?
o SMTP の昔の状態と同じだと思うので
+ 悲観的なことを言うと autioritative サーバは query で来るパケット
より応答パケットが大きくなる
o DNSSEC が入ると悲惨になると思う
o 入れることのリスクは認識している
+ TCPを使えばいいのでは
o 今のDNSぐらいスケールするプロトコルができればいいのではないのか
- 統計情報ネタ by 藤原さん @ JPRS
+ Anycast
o AS23774
o BIND9
o 東京 + 大阪 2004/02-
o NY にも追加予定
+ クエリ概要
o 平均2000qps
+ 試験運用
+ 大阪にASPathを追加すると
o 大阪 63% -> 23%
o 東京 37% -> 77%
+ NYを稼動
o RIPE DNSMON で遅延時間が少なくなったことが確認できた
o 大阪 21% -> 18%
o 東京 79% -> 63%
o NY 0% -> 19%
o アメリカからの query の一部やロシアからの大部分の query が NY へ
+ 大阪にASPathを3つ追加
o 大阪 18% -> 3%
o 東京 64% -> 84%
o NY 18% -> 13%
+ まとめ
o ASPath プリペンドは Anycast でのロードバランスに多少役立つ
o ヨーロッパにニューヨークに近い
+ 予告
o 詳細な分析を実施中
o 発表をJANOG20@帯広で実施予定
そのほか
- Dynamic Update
+ 最近話題にならないけど DNS オペレータ的にどうですか?
o 多分 Windows から AS112 にプライベートアドレスの Update が頻繁に来る
o [zy].dns.jp に 1qps ぐらい来ている
o Active Directory なので組織構造を晒すような Update が来る