[Top Page]
----------------------------------------------------------------------
BoF名 日本DNSオペレーターズグループ BoF
BoF開催団体名 日本DNSオペレーターズグループ
開催日時 2008年07月09日 18:30〜20:40
参加者数(※) 19:00頃 111名
20:00頃 136名
※多少の数え間違いがあると思われる
----------------------------------------------------------------------
イントロ
--------------------------------
o ロゴコンテスト授賞式とか
----------------------------------------------------------------------
SPFの話
--------------------------------
* SPF/DomainKeysの書き方のBCP(山本さん)
--------------------------------
o SPFの動きの簡単な紹介
o 普及状況
- 送信側の普及状況は22.38%
- 昨年の11月ごろに急激に普及率上昇
--> DoCoMoショックと呼んでいる
11月頃から、SPFが無い場合、DoCoMo宛てのメールが拒否される
ようになったのが理由だと思われる
o SPF RRの書式
- 送信サーバの限定子
"+" -- pass (ドメイン名は正当)
- allの限定子
"-all" -- fail (ドメイン名は不正)
"~all" -- softfail
いきなり "-all" だと怖い人は
- 間違えやすいところ
IPv4の場合ip4
IPv6の場合はip6
ブロックの最後の.0は省略できない192.168.0/24とかかけない
- 参照について
includeとredirectの違い
--> includeはもし参照先がOKならばという意味
includeは参照先が存在しないとまずいしループも簡単に起って
やばいので気をつけましょう。
- ワイルドカード
基本的には非推奨
definitiveなので*.example.jpとsub.example.jpの両方を設定すると
sub.example.jpの設定が優先される
- その他
メールを出さないドメインこそSPFを書いてほしい
o SPFの検証
- 書式の検証
http://www.kitterman.com/spf/validate.html
- spfqueryで動作確認
- 本当にメールで確認したい場合
--> spf-test@openspf.orgへメールを送るとそこで検証できる
o 実際の使われ方
- 受信側にはSPFは普及していない
- 転送問題
--> 転送されるとIPアドレスが変わってしまうので検証に失敗
- 解決方法
--> ホワイトリスト方式
--> DoCoMo方式
--> 受信側のみで対応可能
--> SMTP MAIL FROMの書き換え
--> 転送の際にResent-Fromを使う
o Sender ID
- Sender IDはSPF のスーパーセット
- チェックは以下の二つで
--> mfrom
pra
- spf2.0/mfrom,praというおまじないを記載
- 普及の障壁
--> 2004年当時のMSの声明ではサインが必要だった
2006年12月からOSPで自由に使えるようになった
o まとめ
- SPF RRを書きましょう
- v=spf1で十分
- せめて"~all"にしましょう
- Webだけしか使わないなら是非"-all"に
* 質疑
q. 実際に-allで受信拒否している人はいるのか？
a. KDDIはプレスリリースしているけどそれ以外はちょっとわからない
q. INCLUDEみたいな面倒な仕組みについてどう思うか？
a. MACROはいやだけどINCLUDEはそんなに面倒じゃない
q. SPFみたいな仕組みを組織でどのように使っているか知っているか？
a. 半分弱くらい(これは会場への質問だった)
c. INCLUDEはクエリーが増えるからダイレクトに書いてほしい
q. なんか設定するのが大変だけどどうなの？
a. IIJからまともなmilterの実装を出すのでよろしく
q. IAJapanさんのほうで？
a. 受信側で特定のドメインだけSPFを使うとかそういう実装がないなぁとか
その辺に対応したい
q. SPFレコードを書いたときの不利益はないの？
自宅から送った場合とか、その辺の一般的な対応とかはあるのか？
a. 書かないときの不利益と書いたときの不利益の比較の問題です
----------------------------------------------------------------------
DNSの性能評価
--------------------------------
主要DNSサーバの性能と反応速度の比較(杉浦さん)
--------------------------------
o 速度の比較
- DNS性能の測定方法
--> queryperf
性能上限が25万qpsぐらい
--> 測定専用プログラム（つくってみた。dnsattack)
35万qps
--> dns_dos（これもつくった。GbEうまるぐらい）
70万qps
o 測定機器の性能
- authoritative server
--> debian 4.0, Core2 Duo3.1GHz, DDR2, Intel/Pro 1000GT 82541
--> 調査対象
+ BIND 9.5.0
+ BIND 8.4.7
+ NSD 3.1.0
+ DNS dash 1.0 (by NetAgent)
- キャッシュサーバの速度性能
--> 調査対象
+ BIND 9.5.0
+ BIND 9.5.0P1
+ BIND 8.4.7
+ Unbound 1.0
+ DNS dash 1.0 (by NetAgent)
o 試験結果 (queryperf単品/queryperf３つ同時)
- 応答性能比較(応答数)
--> BIND9は4万qpsぐらい。
BIND8は10万弱
NSDは13万/22万
unbound 10万ぐらい/17万
DNS dash 14万ぐらい/23万
- RTT比較(msec?) →過負荷時だからsecだと思う
--> BIND9は0.4
BIND8は0.2
NSD/unbound/dns dashは0.1前後
- 過負荷状態での返答率の変化
--> 比較対象
+ bind9.5.0
+ unbound 1.0
+ dns dash 1.0
結果は資料参照。
o まとめ
- queryperf
性能限界は受信を待つため13万qpsぐらい
キャッシュ済みであればauth dnsとほぼ同じ
- bind9.5.0
threads on にしたがあまり効果がなかった
そのままつかうと4.5万qpsぐらい
- unbound
期待通り早い
- BIND 9.5.0P1
5%ほど性能ダウン
- dns dash
kernel modeで動くやつ、速い。売ってます。
--------------------------------
BIND9の速度の話(服部さん)
--------------------------------
title: BINDマルチコア/プロセスパフォーマンステスト
o BINDはどのくらい性能でるのか？
→ ちなみにNominum製品はマルチコア対応じゃない
- テスト内容
２種類のテストを実施
テスト1：コア数と処理性能
テスト2：1プロセス時と複数プロセス時の比較
セキュリティ機能：queryport-pool機能
- テスト環境
bind9 spec
centos5.2, kernel 2.6.... Intel Xeon 2.3GHz QuadCore*2(8core), 4Gmem
Traffic generator
- テスト構成
bind 9.4.2, bind 9.5.0 queryport-pool 有効・無効を比較
traffic generatorはnominum resperf 1.0.1.0 (freeで使える)
- クエリリスト（2パターン）
すべてユニーク
すべて同じクエリ(100% cache hit)
- BIND設定
cache size 1,400MB
recursive-clients: 50000
source compile
o テスト方法
resperf -s bind-ip -d query-list -m 20000
--> (60秒かけて20kqpsまで付加をあげる)
named resource は top でチェック
o テスト結果
コアの数が2個までのときはqueryport-poolありなしで差はなし
コアが4個以上のときqueryport-pool onだと性能あがらず
cpu余裕あるがbindはだまりはじめる
o 100%cache hit時の結果
資料参照
o bind 9.4.2/9.5.0
multi proc (core *4) vs single proc x4
結論としては、single proc の数増えても性能変わらず??
詳細は資料参照
o まとめ
資料参照
* 質疑
q. nominum はどれくらい性能でる？
a. テストしたかんじではuniq queryで20000qpsぐらい。
q. cache ??
a. yes
q. auth server しらべた。nsd だと fork するプロセスえらべて
その数値で性能が結構かわる。bind9 も使用するcpuの数とかを
選べるので性能がいろいろかわる。(fujiwara)
a. n option=2 で実施した。(sugiura)
c. threads ってOSの性能に依存するところが大きい。
OSとかも単純なプロセスで比較してリニアになるかとか
みるとよい(yasuhiro)
c. 性能があがらないのは、どっかでシリアライズされて
portの乱数生成とかが multi coreになってないきがする。(rikitake)
q. dns dash が早いって聞いたんだけど、source portとかIDの
選び方ってパフォーマンス影響あると思うんだけど、そこらへん
大丈夫なの？
a. dns dash は通過するクエリを覚えて、同じのがきたら
それを返すトランスペアレントなキャッシュサーバのイメージです。
なので乱数処理とかはない。(aikou)
----------------------------------------------------------------------
逆引き
--------------------------------
逆引きDNSに求められているもの(山崎さん)
--------------------------------
o はじめに
- いつも障害の報告ばかりで申し訳ありません
o 逆引きDNSサービスに何が求められているか
- 何に使われている？
- 停止時何が困った？
- 付加価値？
o ぎゃくびきDNSの用途
- アクセス元特定とそれを使った規制
- 見やすさ向上
o 利用の伸び
- DITL2008から
- PTRレコードへのクエリは2007年に比べて横ばい
o JPNIC経由では
- 2003年8月以前に割り振り行われたもの
--> JPDNSでサポート
- それ以降
--> APNICでサポート
IPv6はすべてこれ
o このところの障害履歴
- JPNIC-APNIC連携回りでの障害が多いということらしい
- JPNIC内に閉じた障害は1件らしい
o APNICの障害での影響
q. 実際にどのような不具合がありましたか？
--> 誰もいない！（そんなはずはないが）
c. AS112が入ったときになんかおかしくなった
q. 顧客からきたクレームは？
--> 誰もいない！
a. なんか今日は遅いという問い合わせの件数が多かったような気はする
a. 某掲示板で書き込みエラーになったというのがあったらしい
c. ここに来ている人のところまで話が来ていないのかも？
q. 不具合が発生するまでのタイムラグは？
o どうやったら障害を減らせる？
- JPNIC-APNIC連携の部分についてよりシンプルな新連携システムを構築中
o 付加価値ってあるのか？
q. ログインで使うサービスを増やす必要がありますか
--> sshとかで使っているみたいなやつのこと
q. ID機能の強化が必要か？
q. 更新の頻度をあげる必要はありますか？
q. APNICはほぼリアルタイムで更新しているけどそれと合わせる必要は？
a. それよりトラブル減らしてほしい
q. DNSSECを入れるのは現実的ですか？（APNICからも聞かれている）
--> この辺ほとんどAnswer側の発言がなかったと思う
--------------------------------
IPv6の逆引きについて(伊藤さん)
--------------------------------
o 正引きも含めてIPv6を使う場合の問題
- Interopのワークショップで使った資料の一部を使います
- 2008年2月4日にrootのアドレスにIPv6アドレスが入った
- 使うトランスポートの話とRR(AとAAAA)の話は分けて考えましょう
o AAAAとv6のPTRを書くことについて
- とても面倒
- MXとかNSとかWWWのアドレスはさすがにPTRかかないとだめだろう
- 固定アドレスのPTRは？
--> SMTPの接続元チェックに使われている
SSHの接続元チェックに使われている
o 動的割り当てのアドレスにかんする設定は？
- うまい手がない
--> v6は/64でも16nibbleあるけど
そもそも割り当てはPnPなのにDNSは手動か？
o 動的アドレスのAAAAは人間がチェックに使うことはあまりなさそう
- PTRはなににつかう？
- 身元チェックという意味では静的アドレスより動的アドレスのほうが
重要なはず。そういうこともあるしv6ではDNSに依存するべきではない
という意見もある。
* 質疑(質問タイムだけどコメントのみ？)
c. IPv6の最小割り当て単位は/64だけど、つなぎかえによってアドレスが
/64レベルで振りなおされないようであればあらし対策という意味では
それでいいですよね（質問じゃない）
c. NXDOMAINやSERVFAILみたいなばあいとNOT RESPONDINGでは違うでしょう。
そういう意味で障害発生時に応答が遅くなるってのは何か違う原因もある
のではないか？
c. NGNのアドレスはIPv6だし埋め込みのハードウェアIDが下64bitにくるから
それで認証できるはず。そういう運用上の感覚の違いを運用者が理解した
ほうがよい。
--> 本当にそうなるかどうかはちょっとわからない。
c. IPv6ではそもそも逆引きをいらないという考えもある。
--> たとえば、KAMEのチームはいろいろ相談したうえでIPv6では逆引き
という話になって、それを前提に種々のアプリケーションの実装を
行った。
c. 一般のユーザが逆引きを設定しないという設定ができないようになっている
運用とかもある
----------------------------------------------------------------------
lightning talk
--------------------------------
* Public Suffix Listとその問題点(力武さん)
--------------------------------
o ことの発端
- 2008/6/9 ietf dnsop ML に mozilla なひとから流れた
- public suffixとは？
- 直下にユーザが名前を登録できるドメイン
--> com, co.uk, pvt.k12.wy.us
- 静的データベース/管理はmozilla
o 何故こんなことをするのか
- example.com の cookie が .com の cookie は受け入れないようにする
- UIへの応用例「ドメイン名のもっとも重要な部分」の強調
- ヒストリのサイト別ソート
o listの必要性
- super cookieはdotのないtldのみ(ex: org)
- javascript documento.domain の正当性検査
- http://publicsuffix.org/
--> 更新でメールで受け付ける
- メールアドレスで正当性を判断
o firefox 3 でハードコードしている
- Gecko:TLD Service
o 実際のリスト形式
- com
- *.jp
- *.tokyo.jp
- !metro.tokyo.jp
o trivialな問題
- dns階層と管理階層不一致を無視している
- firefox ver up しないとなおらない
- firefoxがDNS管理手法を決めてしまう
- TLDハイジャックの効果がますます高まってしまう
o もっと問題なこと
- カスタマイズできない
--> .local とかどーすんねん
o 本質的な問題
- web ブラウザ開発者はDNS管理者の意識の埋め合わせることのできない
違いが露呈したこと
- 正しいドメイン名ってだれが決めるのかよ
- DNSを引くのを待てないアプリと人間
* 質疑
c. static hard coding を直すのは比較的容易にできると思う。
いまどきのfirefoxはgoogle dbを引いてあやしいサイト表示とかする
q. cookie の取り扱いをなんとかしたくてやってるんだよね？
a. yes
q. IE や opera は？
a. IE は情報なし、opera もやりたいらしい
c. subdomain 増えたりすると問題となっちゃうし。
c. release の本当に直前になって JPRS に「おかしなところはないか」
という質問がきていた。そのような時期になってしまう体制そのものが
もう何かおかしくないか？
--------------------------------
* IIJのキャッシュサーバ状況(松崎さん)
--------------------------------
o 中期的傾向
- qps 微増
- とある日の24hしらべた
o query傾向
- A とか MX をたくさん引いている
--> AAAA が最近すごく増えている。
--> ほかのISPもそうらしい。vistaか。
o source ipの数は？
- ほとんどのホストからAの問い合わせがある
- 3割ぐらいのホストはAAAAを引いている
--> vistaご購入されているらしい
o query数の分散（一部のユーザがaaaa/ipv6なんじゃね？)
- すごーい longtail で一部の人が投げている。
- 上位１％で5割、上位８％の人が8割。
o まとめ
- aaaa 増えている
- 一般ユーザはまだ引いていない
- 上位10%のユーザが全体の80%を問い合わせしてるらしい
* 質疑
q. aaaa query増えてるけど、それにたいする返事のあるなしとか
サーバがいるいないは？
a. ほんとのホストはaaaa書いてないのでその応答が多い
q. 同じものをしつこく問いあわせする人は？
a. 上位の人は多い
c. aaaa 書いていないケースのばあいは、negative cache される
のでその影響はあると思う。
c. OCNも大体同じ状況、AAAAの割合増えている。10回に1回ぐらいはAAAA。
応答率も上がっているけど、どれくらいの割合かの数値はもっていない。
3割ぐらいはnxdomainじゃないちゃんと答えるやつ。
cname先だったりするので必ずしもaaaaが書かれているわけではない
c. OCNに関しては、OARC の方でで何を聞いているかまとめてあるので
そっちも見てね
----------------------------------------------------------------------
当日公表された脆弱性の話
--------------------------------
* dns vuln.(民田さん)
--------------------------------
o cache poisoning の説明
- attacker が先に答える
o 8月にBlackhatでしゃべる内容はたぶんJANOG19で話した内容
o 基本的には dns query id 16bit しか空間がないことの問題
o BINDのパッチはuse query portとかなくなってランダムになる
DNSSEC以外は根本的な解になってないけど確率は何桁か下がる
o あとは資料参照
* 質疑
q. P1をあてたときにキャッシュにのっていないやつの性能の違いは？
c. キャッシュにのっている場合はあんまり関係ないよね
a. 新しいクエリを生成するたびにソケットつくってバインドしているので
性能はかなり悪くなるだろう
c. WindowsXPで MS08-037を適用後、クエリーソースポートがランダムになり、
Firewallが遮断しちゃって困ったとかいう問題が出ているらしい
* BoF後 DNSOPS.JP ML 上で流れた話
o 一部の distribution における問題
- 標準配布の named.con にわざわざ port 固定している設定が
入っているものがある。
query-source port 53;
query-source-v6 port 53;
その場合、BINDを更新しても効果がないので別途呼び掛ける必要あり？
しかも一部といいつつメジャーどころなのでかなり問題がある。