DNSOPS.jp BoF
* 開会にあたって (JPIX 石田さん)
オフレコにして欲しいときは言ってください。
* アジェンダ
・DNSSEC導入事例紹介
・Simplified DNS Query under IPv4/IPv6 Mixed Environment
・World IPv6 Day(AAAA Filter)
・LT
- 「重複をお許しください」ができるまで
- Number of DNSSEC Validators seen at .JP
- DNSSEC World Map
* DNSSEC導入とトラブル事例 (SANNET 其田さん)
- ご注意
社名は口走っても記録しないように
- まとめ
キャッシュサーバへのDNSSECが起因でトラブルが報告
された事例は無し(.ukなどのTLDのトラブルはあるが)
権威サーバの対応は慎重に。ずばりqmailトラブル
maillogでqmailの数を調べておいた方が良い
qmailつかってるひとはpatchあてて!
- 昨年度のSANNETのDNSSECへの取り組み
2010/07/16 root zone署名
2010/07/20 本番キャッシュサーバ署名検証開始
ついでにfilter-aaaa-on-ipv6有効化
2010/07-12 権威サーバ用署名システム開発・テスト
2010/12 ホスティングサービス署名開始
2011/01/16 JPDNS署名
2011/01/17 ホスティングサービスユーザ向け署名サービス開始
2011/02/07 sannet.ne.jp署名
2011/03 IPv6対応, minimum response on
- キャッシュサーバ構成
LBが上にあり、下に何台かCNSがいる普通の構成
- 権威サーバ構成
導入前
レコードデータサーバ → 設定/ゾーンファイル配布サーバ -(rsync)→ 権威サーバ
- 署名 鍵管理システム
OpenDNSSECを使いたかった
HSM買うお金ない
SoftHSMが重くて使えない(Sparc T1で1threadあたりの性能は...)
DBの冗長性がｘ
なので自分で作った
- 概要図
OpenDNSSECを模倣
署名をする:signer, ゾーンと鍵の状態遷移を管理するデーモン:zone-manager
ゾーンと鍵の状態遷移を監査するデーモン:auditor
signer, zone-managerを自分で作ったので信用できないので
auditorでチェックする。
DBに鍵の状態を入れておいて、その状態になっているかをauditor
で毎日4回checkしている。
- トラブル事例
* トランスファー時のトラブル
DNSホスティングを利用している顧客がドメインをトランスファーアウト
したらそのドメインのWebページが見れない。
フローでは消すようになっているが、ミスった
→ DSレコードを削除しないでトランスファーアウトしちゃったから
対処法:
DSを消して検証を無効にする
ユーザに移管先の会社に連絡してDSレコードを削除してもらうように依頼
→ 移管先がDSのas駆除に対応していることが必要
Q: mailでDNS変更依頼を出すときにDSが(?)書いてなかったらDSってどうなる？
A: 書いてなかったら消えるようにしてる
トランスファーのときはそのままレコードを転送するので消えない。
＞ 空白にしたら消えてないような… ＞ あとは個別で...(笑)
* メール受信トラブル
qmailが512byteを超える応答を扱えない
送受信先のメールサーバ管理者にパッチを当ててもらうように依頼
SANNETのDNSSECのページにqmail関係の注意文を追加
JPRSからのアナウンスで非常に説明しやすくなった、助かった
qmail問題はDNSSECに限らない問題。パッチ当てて！
- Q&A
Q: IIJ山本 デフォルト署名っていうのは社内で議論にならなかった？
A: お客様の安全安心が第一だ、という論調だった。
qmailの問題だけが想定外だった
Q: IIJ山本 .jp直下のドメインじゃなくて、サブドメインだけ預かって
るというパターンはあるか？.jp直下ならDSの登録をJPRSに依頼すれば
いいけど、サブドメインだとDSを上位ゾーンに依頼してください、と
お客さんに言わないといけない。とりあえずIIJのサービスでは.jp直下
だけにしたけど、どうしてる？
A: 「このDSレコード登録してね」と表示するかメールするかするかとも考
えたが、場合分け・考えることが多すぎて止めた
Q: SO-NET山田 リソース食うよとか、データがデカくなるよと言う話があ
ったかとおもうが、実運用して気がついた点があれば教えてください。
A: CNSのCPU使用量は上がってない、メモリ使用量もたいして上がってない。
DNSSECに対応しているところが少ないからだと思う。
* Simplified DNS Query under IPv4/IPv6 Mixed Environment
IPv4/IPv6混在通信環境における適切なDNS名前解決方式(NEC/電通大 北村さん)
表題の件で現在IETF DNSEX WGでI-dを議論中
内容紹介および議論とコメントをお願いしたい
現状1つのノードについてv4/v6両方のアドレスが設定 = A/AAAAと、種類
の異なる複数アドレスが設定されている。これっていいの？もっとシンプ
ルなトラブルの少ない方法があるんじゃないの？という想い。
IPv6導入促進的な意味でユーザにとってA/AAAAはどうでもよくて、FQDNが
重要で唯一のもの。DNSのクエリの所で失敗したらv6ダメじゃん。というこ
とになってしまう。
v4 onlyの世界でも、あるFQDNに対してAが複数というのはありうる。でも、
これは1回qtype Aの問い合わせをして1つのパケットで応答が返ってくる。
1pairである。
v4/v6 dualではA/AAAA独立した問い合わせ・応答(2pair)になる。
これは以下のような理由のため、2pairになっている。
・v6黎明期にv4に影響を与えないようにするため
・AAAAに対応していない権威サーバのため
・AAAAを優先させるため
A/AAAA別に名前解決する場合、4種類の仕方がある
・4-6 serial(Windows7/FreeBSD)
・6-4 serial(WindowsXP)
・4-6 parallel
・6-4 parallel
2pairの名前解決の問題点とは「複雑である」こと
1pair片方だけ落ちたらどうするの？再送とか頭痛い
simpleさを損なう
serialでやると2倍時間がかかる。ペナルティを受けている
DNSサーバのAAAA対応が進んだ。非対応のANSはほとんど無い
クライアント側もAAAAにほとんど対応している
提案：1pairでA/AAAAを取得できるようにしよう！
1. two existing records combined型
2. one new special record型
3. one existing record w/ mapper transformation型
1.
query setcionのtypeにA/AAAA 2つ書けるようにする
構造的には出来る。でも、そんな例はない
クライアント側に手を入れるのが大変
1queryには1つしか入れないという暗黙的なルール(?)を破ることになる
2.
新しいquery typeを作る
AAAAA？(ペンタA？)
やっぱりクライアントに手を入れる必要がある
3.
AAAAを聞いたらIPv4のmapped addressも返してあげる
独創的
全てののアドレスはIPv6アドレスで、AAAAレコードだけで事足りると考える
クライアントに手を入れなくてもよい
いささかトリッキーだが、基本的には問題ない
まとめ
長期・理想的な視点だとクライアント側の実装を変更する1, 2
実用的な普及を重視するなら3.が有力
ご意見
Q: これって権威サーバでやる必要ある？
A: キャッシュサーバでやってもいい。権威サーバでも良い
2.はIPv6の次を考えないといけないから無いなぁ
1.はまぁ動くんじゃないかな？
mappedアドレスってもうobsoじゃないの？まだ生きてる。rfc3484で。
mappedアドレスでびっくりするクライアントが無いか？
＞ 何個かためしたが平気っぽい(?) ＞ ホームゲートウェイあたりであるかも…
mapped addresはLinux系では有効、BSD系では実装されているけど設定で無効
になっている。
DNSSECとかANYで聞かれたときのことも考えないとダメだね
会場でアンケートとってみたら？
取るなら現状維持もお願いします。
アンケート結果:
今のままがいい: いっぱい(短期的にはという声有り)
1: ちらほら
2: ほとんどいない
3: ちらほら(1と3同じくらいか3が若干多いか？)
* AAAA filter(World IPv6 day) (IIJ 松崎さん)
- めでたいこと
APNIC IPv4通常在庫枯渇
そろそろ心配してください
/127がRFC(standar track)に
ベンダーのみなさん実装をお願いします
結婚しました！！
おめでとうー！
- (サーバー側)IPv6対応で生じる接続障害
主にv6->v4 fallbackがうまく動作しない
IE7だとよくわからないけど5%くらい失敗するらしい
IPv6のInternetの疎通があれば問題ない
- ごまかす方法
キャッシュサーバーでAAAAを応答しない
IPv6対応接続用のキャッシュサーバーには削らないものを、IPv4しかなくて
IPv6閉域網に接続してる接続用のキャッシュサーバーには削るものを用意する
- BINDでの設定方法
./configure --enable-aaaa-filter
named.confのoptionsに"filter-aaaa-on-v4 yes"追加
二回踏み抜いてください
- BINDでfilterをONにしたときの挙動
A/AAAA → AAAAを応答しない
AAAAのみ → AAAAを応答する
AAAAのみのホストを聞いていると言うことは、ユーザがなんらかv6の
reachabilityがあるのではという推測から
filterをonにするとちょこっと権威サーバへのqueryが増える
キャッシュに乗ってない初回だけちょっと応答が遅くなる
- 対応の利点
コンテンツ事業者が安心してIPv6対応出来る
IPv6閉域網に接続したユーザでfallbackが無くなる(遅延がなくなる)
- 対応の懸念点
IPv6閉域網に接続したユーザがインターネット側のAAAAを検索できなくなる
IPv6トンネルとか使っててISPのキャッシュサーバーを見ていた場合
ISPが運用するDNSサーバが増える
- ご意見、Q&A
Q:ISPは設定したらいつまでやる？
A:状況が改善するまで。根本的にはIPv6の接続を提供すればいい
Q: filterしたときのパフォーマンス劣化って計測した？
A: 応答パケットを作るときにちょっと細工するだけだから、そんなに
劣化しないはず。でもACLの行数は気にした方が良いと思うよ
breakdnssecにしないと署名している場合は削らないよ
IPv4アドレスベースでfilterするしないのACLを書けるので、1種類でも
出し分けが出来る
そのうち対策推奨の文章がでるかと。
* LT/「重複をお許しください」ができるまで (JPRS 森下さん)
- アジェンダ
- 生い立ちと状況
- なぜいつも同じ書き出しなのか？
- 主な分類
- ケーススタディ
- 出来るまでの流れ
- (
- 生い立ち
技術コミュニティ系MLにマルチポストの形式で出す「お知らせ」の書き出し
初出10/06/09 [janog:09571]/[DNSOPS dnsops 929]
11/04/19までに24通。2週間に1通。DNSSEC関連アナウンス15通, BIND脆弱性5通 たいして多くない！
- なぜいつも同じ書き出し？
MewでEと打つと過去メールの再利用。自然と同じ書き出しに
IW-2010の会場で「「重複をお許しください」をMLで見ると緊張が走る」
「仕事が増えるフラグ」と言われた… 私が増やしているわけではないはずです！
- 主な分類
DNSに関連する…
セキュリティホールや不具合などの注意喚起
インターネット全体に影響がある情報のアナウンス
技術文章公開のお知らせ
今日は1番目を解説
- ケーススタディ
BIND9の脆弱性
ISCからの"Advance Security Notification(ASN)"が重要な情報源
JPRSがbind forumに入っていてpremimサービスを受けている
大体1週間前にお知らせが来る
2009/07のBINDコロリではASNでの公開から間を置かず公開された
ASNが届いたら…
1) ASNをざっと分析 危険度/対象/既にExploitがあるか など
2) 出すかどうかを判断 severity:highだと青くなる
3) ASNを再度詳しく分析
何が悪いのか：実装？プロトコル？設計？構造？
できちゃうことはなにか？
何をすればいいか: workaroundとsolution
4) 文章の素案を作成
タイトルを決める
「(緊急)」の有無、推奨度(「〜を(強く)推奨」(など
構成を決める
基本的にはテンプレ
5) 文章の中身を作成
作成とレビュー
テクニカルレビュー(正しい事を書いているか)
広報的レビュー(わかりやすい文章か)
6) 動作の確認(追試)
書いてあることが実際に起こるかどうか。重要な事項では特に注意して実施
7) アナウンス
- ISCのWebで公開されているか。CVE/CERTも確認
- JPRS Webの更新
- MLへ送信
8) アフターフォロー
情報の広まり具合
重要な2メディア: twitter, セキュリティホールmemo
セキュリティホールmemoに載ると急速に広まる
検索エンジンの状況(掲載状況、順位の変化)
blog、各種メディアなど
問い合わせ対応
- 気をつけていること
「概要」を読むだけで対象、何の不具合か、何が出来てしまうか、情報源、
危険性、どうする必要があるか、をわかるようにする
「対策」は簡潔に記述する。かつWorkaroundとsolutionを明確に区別
「詳細」はこの場に来ているような人向け。興味を持った人のために記述
「詳細」を読まなくても必要な対応が出来るように
「例外条件」はここに記述
- ケーススタディ: qmailの512byte問題
開発元の公式発表などではないので情報源の項目がない=JPRSが発表した
ことになる
なので「背景」に根拠と事実を書いた
- まとめ
必要に応じて、出来るだけ迅速に出す予定です
文章作成技術や広報技術に関する様々なノウハウを蓄積・共有していけれ
ばいいなと思います
繰り返しますがさんが仕事を増やしているわけではないです
淡々と必要な対応をお願いします
- 番外: qmailの件について5+1の「まずいところ」
- 送り側が何年も設定を変えていないのにおかしくなる
→ 送れないのは自分の性だという認識が薄い
- 受け側がDNSSECを入れたところだけがおかしくなる
→ 相手が設定を間違えたに違いないと思われる
- SMTPセッションが張られる前にこける
→ 受け側でエラーが起こっていることがわからない
- エラーメッセージからは真の原因がわかりにくい。しかも4xx(tempfail)
"CNAME lookup failed temporarily. (#4.4.3)"
- デフォルトでは1週間後に初めてエラーメールが戻る
→ 受け側でのDNSSEC導入後、しばらくは発覚しない
- +1: qmailの"q"は大文字じゃねぇ！というご指摘
* LT/Number of DNSSEC Validators seen at .JP (JPRS 藤原さん)
- DNSSECの普及率を数えろとのお達し
- どうやって数えるか
.jpのDNSKEYのTTLは1日
→ DNSSEC対応のキャッシュサーバはJPのDNSKEYを1日に1回取りに来るはず
→ a.dns.jpで数えて7倍すりゃ良いじゃん
- JPRSのデータ
年2回のpacket capture
7年分のquery log
- captureした1日でvalidator 2400-2700くらいでした
- 緩やかに増えていってる。震災直後はちょっと減りました。
* LT/各ccTLDのDNSSECのステータス地図を作ってみました。
(ブロードバンドタワー 大本さん)
- きっかけ
DNSSECジャパンの技術検証WGで海外動向を調べていこう
.toドメイン持ちだったので
- 作り方
最初はtwitterやwebサイトの情報収集で手作業
自動収集にしたい
- 自動収集
メールで定期的にdigして結果をおくるshell scriptを作った
KSKの存在確認していたが、.nuがZSKのみの運用だったので変更した
- 地図あそび
初めはkmzファイルをgoogle earthでas区政
kmlファイルの作成が大変
Google earthで国境をなぞってポリゴン作って、色つけて…
これでもccTLDのDNSSEC対応のスピードが緩やかだったので事足りていた
rootが署名された7月以降、2010/9から急に速度が上がった
とても間に合わない
そうこうしていたら公開していた地図・資料が10末頃から消えた
＞ 師匠に相談したら「自分で作ったら？」
- 作ろう
Helio WorldでWeb向け地図を生成できるらしい
phpで理解しやすいコードとconfig
できた。けど、ヨーロッパは国が小さくてわかりずらい
モンテネグロがなぜか色が出ない。というか国がない
マレーシアとシンガポールが逆
プエルトリコは島自体がない
＞ 国境定義用のphpコードを弄って変更
完成した直後に.net/.asiaがDNSKEY公開したのでgTLDの更新状況も対応
させるようにした
履歴を残すようにした
最終的には現在の1枚ページになりました
http://www.ohmo.to/dnssec/maps/
- 傾向
小さい島国のDNSSEC対応速度が速い
- 今後
IDNどうするかなぁ
DNSSECテストしているというアナウンスを自動的に拾う仕組みがない
.gi .li .scとか小さい国はhelioは元々地図表記を準備していない
＞ とりあえず.liは書いてみた
白地図だとどこの国が対応したかわかんない
＞ ヨーロッパは国コードを埋め込むようにした