2012/04/25 DNSOPS.JP BoF＠品川イーストインタワー21F 18:00〜 ■ 10分で分かる幽霊ドメイン名と浸透問題の関係（JPRS 森下さん） - 幽霊ドメイン名とは？ 2012/2/8に論文で報告: Ghost Domain Names （段海新＠清華大） 上位ゾーンで委任情報を削除・変更しても古い情報を参照し続けるよう 仕向けることができる。 - 何ができる？ 不正な目的で使われているドメイン名の強制的削除を妨害される。 （NS削除の妨害） 不正使用されているドメイン名の強制移転を妨害される。 （NS強制変更の妨害） ドメイン名を新規登録したにもかかわらず、昔のNSが残ってしまう。 （幽霊つきドメイン名） →全てのキャッシュDNSサーバに対してではなく、局所的に引き起こされる。 - これはいわゆる「浸透問題」では？ 幽霊ドメイン名も浸透問題も、「古い情報が使われる」という結果は同じ。 →浸透問題対策が不十分であった。 + 浸透問題はBIND 9.2.3で対策された 攻撃方法: キャッシュDNSサーバーに、キャッシュから消える前に問い 合わせるだけ。攻撃しているつもりがなくても攻撃になる。 対策: NSレコードが同じだったらTTLを更新しないようにした + 幽霊ドメイン名では、BIND 9が取った上記対策をすり抜ける方法が使われる 攻撃方法: NSレコードは違うが、それが指すA/AAAAの内容は同じという 状況を作りその名前をを意図的に検索させる - BIND 9に幽霊ドメイン名への対策がなされた →ちゃんとバージョンアップしましょう。 + 対策：TTLを巻き戻さない Unboundは「浸透問題」対策として実施していた。 TTLはキャッシュしてよい時間なので短い分にはRFCに矛盾しない。 - もっと詳しく知るには？ 段海新氏のグループの論文 JPRSの技術文書 Geekなぺーじのblog記事: http://www.geekpage.jp/blog/?id=2012/3/21/1 ■ GREEにおけるDNS運用とPrimDNSについて（GREE 恵比澤さん） - GREEのサーバ運用 DCの構成 サーバ管理方法など ＜詳細略＞ →プライベートクラウドっぽくなっている。 - GREEで使われているDNSについて 権威DNS（インターネット）→普通にBINDとかCDNとか 権威DNS（内部サーバ） →ここでPrimDNSを使っている ＜詳細略＞ - PrimDNS開発の経緯 内部ドメイン名のニーズ プライベートクラウドから必要に応じてサーバを提供 内部サーバの用途などを内部ドメイン名でわかりやすく把握したい。 サービスが頻繁に動くので内部ドメイン名も頻繁に更新される 昔はtinydnsを使っていた サーバ管理DBからゾーンを生成 →スクリプトを組んで運用負荷を軽減 →最終的に面倒になった 欲しかったもの 社内のサーバ管理DBを直接参照できる 何もしなくても変更が反映される 軽量でコンパクトな実装 マルチスレッド 一般的なデーモンのように使える - PrimDNSの特徴 動的なレコード生成が可能 外部コマンドの実行結果を応答として返す 生成されたレコードをキャッシュ 重い外部コマンドでも利用可能 同じゾーンで動的なデータと静的なデータの併用が可能 - PrimDNSの稼働状況 1.5年ほど動いている（qpsは略） 90％程度はキャッシュヒット - オープンソース化について BSDライセンス もともとオープンソースに積極的な会社だったので許可が出た →というか促された？ 現在は個人で開発中 ご興味のある方は声をおかけください github: https://github.com/ebisawa/primdns - DNSSEC ……未対応です… 質疑: Q: なぜDNSサーバを作ろうと思ったのか？ A: 日々の運用の改善には力を入れる価値があると思った。 Q: 単純に考えると、外部コマンドでPULLするよりも、サーバ管理DBから 変更内容をPUSHさせたほうが楽なのでは？ A: サーバ管理DBは既存のシステムなので、手を入れたくなかった。 Q: Unboundの倍のパフォーマンスが出るものを作るのはすごい A: インフラ部門では運用系と開発系が協力していて、運用を楽にするツール がほしかった。あと、そのときはとにかく何か作りたい気分だった。 Q: キャッシュはいつ消えるのか？ A: 普通にTTLを持っています。 Q: TTLの決め方は？ A: 固定データは長め、dynamicは短めにしている ■ DNSSECステータス地図とIDN対応への壁（BBTower大本さん） ccTLDのDNSSEC対応状況を知るため、ステータス地図とメールによるnotice機能 を作ってみた http://www.ohmo.to/dnssec/maps/ 最近ICANN42のDNSワークショップで使われていてうれしい。 ICANNのカウント数と合っていない？と問い合わせがあった →IDN TLDには現状では対応していないため、IDNは現在13TLDが対応済 →ということで、地図にIDNのステータスも出そう 以下、IDN対応奮闘記 第一話: Windows XPとIDN IDN対応には、Webコンテンツの文字コードをUTF-8にしなくては 確認すると、一部（スリランカのシンハラ語など）が化ける Windows XPにはシンハラ語のフォントがない スリランカ政府のWebサイトにて言語パックを配布している Windows 7ではシンハラ語フォントが標準で実装されている 第二話: PuTTYではうまく表示できない CentOS 5に言語パックを入れてもだめ PuTTYはシンハラ語フォントに対応してない 第三話: VPSコンソールとIDN DNSSECステータス地図はServersMan@DTIを使っている ブラウザからのコンソールならいけるのでは？→だめ さくらのVPSだと？→RHEL 6系なのでシンハラ語が表示できる 第四話: 右から左からIDN IDNなTLDをdigすると、出力結果がおかしい アラビア語などだとdigの表示が異なる カラムの順番が入れ替わっているように見える ファイルに落とさずストリームで処理することにした 結局、ファイルに出力してもうまくいくことがわかった 第五話: メール送信機能とIDN メールが文字化けする →メールの文字コードをUTF-8にした 最終話: HelioWorldを使っているが、IDNな文字列だと化ける 文字列の描写には、PHPのimagestring関数を使っている ASCII文字のみ対応している 他の関数を使う？ imageloadfont関数はビットマップフォントだけ imagettftext関数ならTrue Typeフォントを使える が、フォントの切り替えができない セミコロンで複数指定しても、最初に指定したフォントしか使われないようだ 今のところ、IDNを地図に出せない 質疑: Q: 内部処理はPunycodeで扱えば楽ではないか A: 実は、idnkitがあらかじめインストールされていて、勝手にそうなった 最終的に地図に出すところで嵌った C: 「実践DNS」でも多言語だと印刷できず、Punycodeで表記した C: 「Arial Unicode MS」なら1つのフォントで複数の言語の文字が出せるのでは C: PHPに描画させるのではなく、あらかじめから画像として用意しておけば？ →それはいいかも Q: 1つの国が複数のIDNを持つこともできるが、地図にどう表記するのか？ A: gTLD向けに地図ではなく別の表示枠を作ったので、そちらで同様に扱う ことを考えている Q: .asia、.euなど国より大きな範囲のlocal presenseを要求するところ は地図にどう表記するのか？ A: .euはccTLDだが、gTLDの表示枠に入れている ■ DNSSECの提供する信頼性に関する一考察（無所属 藤原さん） - DANEについて PKIは信頼できる第三者が審査を行っている DNSSECは？ DANEはTLSA RRに証明書を登録できる 自己署名証明書を作ってTLSA RRにおく ブラウザはTLSA RRを検索し、自己署名証明書を信頼してTLS通信を行う 新規にTLSクライアントを書く必要がある サーバ証明書にはいくつか種類がある + ドメイン認証 → メールを受け取り可能ならば取得できる + 組織認証 + EV SSL 買い物ならEV SSLがいいが、組織認証とドメイン認証の違いはブラウザの 表記上分からない →証明書のユーザから見たら手間がかかるだけ DANEは、ドメイン認証のSSL証明書と同じレベル DNSへの登録の悩みどころ TLDからrootへのDS登録はsecureだと信じる registryから見たらregistrarしか直接見えない registrantはregistrarを信用するしかない registrant<=>registrarの認証 普通パスワード認証だったり メールアドレスでパスワードリカバリできたり 登録時に送られてきたID・passwordのまま DANEのみに頼るモデル ある名前空間で + TLDレジストリがレジストラを完全に信用でき + レジストラが組織認証を行い + DS登録を取り次げる ならいけそう 結論 DNSSSEC+DANEでサーバ証明書がいらなくなるわけではない 組織認証やEVは必要 個人ユースならDNSSEC+DANEでよいが、TLSクライアントの実装がないので しばらくは安いSSL証明書を買えばいい - root blackout [DNSOPS dnsops 1189]に投稿した対策案: full resolverにルートゾーン を持たせる 問題 - unboundはむり - BIND 9ではDNSSECが機能しなくなる BIND 9 full-resolver viewにroot zoneを持たせればよい 質疑: C: rootのDNSSEC鍵管理はSSL証明書のCAと同等のことをしている Q: 認証局の立場としては、Common Nameが本当に申請者のものかを確認する ことをやっているしかしそれはゾーンに書く人ならわかるはず EVは組織の名称も確認しているが、SSLで通信したいだけならDANEで十分 と思っている人はどれくらいいるのか。 SSL証明書にお金を払わなくてもいいのは魅力となるか？ A: （会場から反応なし） C: レジストラが頑張った結果をレジストリのデータに反映する仕組みがない C: レジストラがEV SSLしたいなら、レジストリ側でレジストラ側のレベルを TXTレコードなどで表示すればよいのでは？ C: Chain of trustを使う立場と提供する立場が整理されていない DNSSECとPKIが誰にとってどれだけのメリットを享受されることが期待され いるか、コストと効果についてよく考えてみる時期にきている （以下root blackoutの件） Q: 電気通信事業者がルートゾーンのコピーをリゾルバーに仕込むことに問題 はないか？ルートDNSサーバのオレオレanycastインスタンスを上げるのは いいのか？ A: ルートDNSサーバのオレオレanycastインスタンスは気持ち悪い A: inter-domainで広報するとまずいと思う A: NeustarがDNS Shieldというのをやっていて、ISPの網内にNeustarが 抱えているゾーンを持てる Q: Op Global Blackoutで仕事が忙しくなった人はいるか？ C: DNSサーバではなく、DNSオペレータに対するDoSだった ■ DNSSEC Ready Check 三兄弟（キャノンITソリューションズ 田中さん） 若手オペレータにIPv6/DNSSECの話を振ると、普及もしていないのに面倒だと 言われる →どのくらい使われているか調べるツールを作ろう！ Twitter: @v6chk（次男） @v6chk [r] domain | word とつぶやくと返事する rをつけると結果をRTしない チェック内容 - TCPを破棄しないこと - DOに対応していること - EDNS0に対応していること - DOのない問い合わせにDNSSECの応答を返さないこと それぞれ、#dnssec_ready、#ipv6_readyハッシュタグをつける キーワードは誤変換することもある だめなときは直接ドメイン名を 込み合っているときはしばらく時間をおいてください 長男と三男もいる 長男: 定期的に、次男にドメイン名をつぶやく 三男: 次男がつぶやいた結果のまとめをつぶやく 上場企業のDNSSEC対応状況は？ 日本企業: IPv6: 0.4％ spf 32.9％ dnssec 0.4％ 一般企業: IPv6: 0.2％ spf【！書き漏らしました！】 IPv6 / DNSSECの対応状況は1％未満 サポートベンダーの力量にかかっている まとめ 厳密な統計情報ではありません。 140文字、150回/hの制限があります DNS設定の誤り、ツール不具合などがあります @ipv6_ready、#dnssec_ready、#ipv6_readyをごらんください ドメインリストください 画像アイコンください ruby 1.9 + dnsruby + twitterライブラリ で動いています 質疑: Q: ドメインリストは個人情報にかかわるので、レジストリでは出していない みんなに自分が知っているドメイン名をチェックしてもらうとよい C: 流量制限のせいで、大量のドメイン名を流せない 裏のコマンド経由で流したりしている Q: Google検索でsite:jpするとたくさんひっかかる。 頑張ればJPドメイン名を列挙できそう。 C: SPFの普及率を測定するのに、JPRSからリストを貰っているところもある はず。 Q: IDNの扱いは？ A: まだ対応していません。 Q: つぶやきが勝手に短縮URLになることがある。短縮されないように工夫して いただけるとありがたい A: 意図したわけではない、勝手になってしまう。 C: ""でくくると短縮にならない ■ バリデーション対応サーバの状況（SANNET 其田さん） DNSSECのバリデーションの状況 20％前後を検証している そのうち60％弱が成功、40％がnxdomain、0.15％がbogus DNSを利用したGSLBでミスがあると、n万件レベルで検証失敗になる 検証失敗事例 2012/1/25、某大学で署名（RRSIG）の期限切れ サポートセンタに連絡あり。署名が古かった。 DNSSEC関連のログを吐かせ、insecureでないbogusログを抽出した。 某通信会社 bogus中のjpドメインはチェックしてる 連絡して即時復旧 JPは意外と失敗していない。現時点で6事例を把握している TLDがDNSSEC運用に失敗したときの防衛策 しくじってもすべて引けなくなるわけではない キャッシュに残っていれば大丈夫 TLD配下でopt outされているものはOK TLDのキャッシュが飛ぶ前に、validateを無効にすればよい →SANNETでは5分おきに観測して、検証失敗したらDNSSEC検証を停止する しかけを入れた 質疑: Q: 今までDNSSEC検証を停止するしかけが発動したことは？ A: ない Q: 通常query/DNSKEYやDSを送るバリデータの比率は？ A: 今すぐにはわからない C: だいたい20％くらいではないかと推測される Q: 検証が停止すると其田さんの携帯電話が鳴るのか？ A: メールは飛ぶが電話は鳴らない。検証が成功すると自動的に再度有効に なる。 Q: 其田さんが万一事故に遭ってもシステムは動き続ける？ A: キャッシュサーバ「は」大丈夫 Q: DNSSECの問題だということがサポートセンターで切り分けられたのか？ 教育がよいのか？ A: Yes.切り分けツールを提供して確認してもらうことはしている。 ■ Google ChromeとDNSSEC （無所属 民田さん） Google Chromeは、ルートゾーンのトラストアンカーを内蔵している SSL接続を行うとき、ドメイン名の認証にDNSSECを使う（I-Dが出ている） http://dnslab.jp/chrome/ に情報をまとめた 検証はSSL経由（DNSを使っていない） Android 4.0以降にも入っている 質疑: C: Googleには、次はWorld DNSSEC Dayといううわさもある ■ この際、DNSSECに言っておきたいこと - がんばってDNSSECやらないといけないの？ 労力に見合う対価が得られるの？ →やっても意味がないと思っていることを、やらなきゃならないでやると 破綻する。 - DNSSECジャパンの活動を通じて、DNSSECへの対応が思うように進まないと 実感した - DNSSEC導入はソフトウェア開発に比べれば全然簡単なはず。 →結局、普通の会社にDNS専門のエンジニアがいないのが、一つの理由では →DNSSECの問題ではなく、DNSの問題である。 →運用者の技術の底上げが大事 - DNSSECを導入するメリットを示すのは難しい。 セキュアといわれることに関して、どういうリスクがどのように現実化して いて、どれくらい損失が発生しているということを具体的に示せればよいが そんなものはない。 - 古い実装が駆逐されるのにも時間がかかる。 - レジストリがDNSSEC対応ドメイン名の登録料金をキャッシュバックすると 普及するのでは？ →.se、.czでDNSSEC discountがすでにある。 2.5％ cashbackだと反応がなかったが、5％ cashbackだと大反響だった ■ クロージング - これからもDNSOPS BoFを継続して開催していきたい （会場より賛同の拍手）