■「DNSSEC導入とトラブル事例」(SANNET 其田さん)
・まとめ
- 今のところキャッシュDNSが原因でトラブルが報告された事例はない
- 権威 DNS の対応は慎重に
qmail に問題がある
MX レコードがあるノードを署名する際には、qmail にパッチ適用が必要
・経緯
- 2010/4
テスト系DNSサーバにてテスト開始
- 2011/2/7からsannet.ne.jp署名
qmailのサイトから届かなくなった
- 2011/3
IPv6対応
→パケットサイズが大きくなってしまうため、minimum response 有効化
・署名・鍵管理システム
- 本当は OpenDNSSEC を利用したかった
HSM を買うお金がなかった
SoftHSM が重くて使えなかった
DB の冗長性が×(当時MySQLへの対応が途上だった)
→署名・鍵管理システムを自前で作った
ゾーンの状態遷移を監視するデーモンを設置
（自分の作ったプログラムは信用しない前提）
・トランスファーアウト時のトラブル
DNSホスティングを他社に移管した顧客が、そのドメイン名のWebページを見られ
なくなった
移行元には署名されたゾーンファイルがあったが、移行先は署名されていない
ゾーンにも関わらずDSが登録されていた
- 対処法1
ユーザに、移管先の会社に依頼してDSを消して検証を無効にする
移管先がDSの削除に対応していることが必要
- 対処法2:
署名の検証ができるようにする。SANNETの権威DNSサーバでは
契約期間内には署名したゾーンが残っている。
Q: 事前に削除してからDSを消すこともできるのではないか
A: 今回はそのように対応していなかった
Q: DSを書かないでメールの申請を書くとどうなる?
A: トランスファーは指定事業者のポインタのつけかえ、レコードは変わらない
いままで通りの申請をすると、DSがないので、DSは消える
Q: トランザクションのところでDSのキーが消えないのではないか
A: (JPRSに)個別にご相談ください
・メール送受信のトラブル
送受信先のメールサーバが512byteを越えるDNSを扱えないqmail
問い合わせが数十件発生
送受信先のメールサーバ管理者にパッチを当ててもらうように依頼
SANNETのDNSSECページにqmail関係の注意を掲載
http://www.sannet.ne.jp/security/dnssec/
JPRSのページに掲載
qmailの問題はDNSSECに限らず起こる問題
Q: 顧客のゾーンのデフォルトでDNSSECを署名する設定が話題になっているが、
社内での議論はあったのか
A: 安全安心を優先した。顧客は中小企業が多い。qmailの問題が大きいのは
予想外だった
Q: .JP直下の場合にはよいが、他のドメインのサブドメインを預かる場合はあるか?
A: いまのところないが、例えば sannet.ne.jp の配下にサブドメインを作れば
できる
C: 当社もDNSSEC対応サービスを作ったが、サブドメインを扱っている場合には、
このドメインを上位ゾーンにDSを登録してください、あるいは解約時に先に
DSを削除してください、などの課題があるため、今後の課題としている。
C: ユーザにDSをアップロードすることを依頼する必要がある
C: 絶対にトラブルが発生する
Q: DNSSECをいれるとリソースを食う、保存する情報量が増えるなどの話があると
思うが、実運用したときに気づいた点があれば教えてほしい
A: キャッシュに関してはそこまで変化がなかった。CPUに関してもあがって
いない、メモリ使用量も変わっていない。
■「Simplified DNS Query under IPv4/IPv6 Mixed Environment」
北村さん (NEC/電通大)
・背景
draft-kitamura-ipv6-simpple-dns-query-01.txt というIDを DNSEXT WG で
議論中
http://tools.ietf.org/html/draft-kitamura-ipv6-simple-dns-query-01
IETF 79 (Beijing) で発表したが、プラハではチェアにひっかかってしまった
・課題
一つの通信ノードにIPv4とIPv6の二つの名前を付けることになっている
IPv4の場合には複数のAが帰ってくる
IPv4だけのDNS名前解決処理に影響を与えないこと
AとAAAAの問い合わせと応答は別にだしている
現状の2対のメッセージ方式によるDNS名前解決処理方式の課題
-> 複雑である、非効率である
シリアルの場合には、Aを取ってからAAAAを取るとペナルティになる
2ペアメッセージのやり方をやめて1ペアのクエリー、レスポンスを行う
方法を3つ考えた。トラフィックも少なくなる
・Two Existing Records Combined 型
ワンペアでごっそり取りたい。クエリに複数書く。
構造的にはできる
2つまとめたクエリを出すのは例がない
クライアント改修が必要
1クエリには1つのタイプしか指定しないのが暗黙の了解
・One New Special Record型
新しいレコード(例えばA+AAAA: ペンタA)
新しいレコードを用意する必要がある
クライアント改修が必要
・One Existing Record w/Mapped Trans 型
全てのレコードはAAAAだと思う、答えもAAAA
IPv4 は Mapped アドレスを利用。
いまあるものをそのまま使える
kernel で mapped address が有効であれば OK
トリッキーだが認めてしまえば問題無い
皆さんのご意見を
Q: 権威サーバでやる必要は無い、キャッシュサーバでやる
A: One New Specialはない。IPv6の次のプロトコルがあったら対応できない
C: その方法は提案として2回か3回でてきている
C: Query Section を増やしていくのはある。1個である必要は無い
C: まだ動くと思う。いろいろなものを実装しなければいけない
Question Sectionを一つだと思う実装が多そう
C: Mapped address はRFC3484がいまだにStandard Track。obsoleteではない。
(RFC3484は)アドレスの選択順序がよくない。フラットならよい。
C: 1,2はDNSEXT WGでは無理で、3はBEHAVE WGならありうる
C: Linux系はほとんどのMapped Addressは有効になっている。FreeBSDでは
機能としてはインプリメントされているが、itojunさんによりデフォルト設定は
rcで無効になっている。クロスしてしまうから問題という考え。
Q: ちゃんとプロキシを実装していれば大丈夫ではないか
C: DNSEXTは理想を求めているが、今回の目的は既にIPv6を使っている
長期というよりは短期を考えるならone pair
C: DNSSECをがんばらないといけない
C: ANYがきた場合もがんばらなければいけない。決めの問題だが。
C: ContentsサーバにAAAAのMapped Addressを書けば答えるのではないか
A: WindowsにIPv4アドレスをつけなければIPv4で問い合わせないのではないか
あとはトランスレータで対応する。DNS64の考え方に近い
やるのはシンプルにしたいがゴール
Q: クライアント側はキャッシュサーバがそのcapabilityを持っているかわからない
A: BIND9などが対応していれば、サーバ側がメンテナンスされていれば
対応できるのではないか
C: クライアント側がAAAAだけを聞けばいい状態にできないかもしれない
C: アプリを改修するぐらいなら、2回問い合わせをするのが気にならなくなる
ほうが先ではないか
C: 将来を考えるといつまでAを引くのか
C: 将来新しいプロトコルが出てきた場合の対応も考える必要がある
A: IPv6 Mapped Address が出てくるのではないか(笑)
Q: ホームゲートウェイが鍵。そのあたりをうまく乗り切れるのならBEHAVEを使う
・会場の意見を。
いまのままがいいという方は0、1,2,3という選択肢で挙手
0: 多数
1: 10数名程度
2: 0名?(確認出来ず)
3: 5名程度
いつこれをやりたいか、どこまでいじれるか
Q: Aを聞いたとき、AAAAを答える方法もあるのでは。
びっくりして多分捨てられる
入れるとしたらAnswerではなくAuthoritiveかAdditional
C: EDNS0で出来るのではないか
C: EDNS1の定義が必要かもしれない
■AAAA Filter (IIJ 松崎さん)
・めでたい話
APNIC IPv4通常在庫が枯渇
/127がRFC6164 (Standard Track) に
結婚しました!
・どよーんとした話
IPv6->IPv4フォールバックがうまくいかない
日本だとホスト名にAAAAをつけただけでは5-8%のユーザが見れなくなる
AAAAをつけているIIJや総務省のホームページ
ほとんどの場合、IPv6接続性があれば問題無い
NTT東西のFlets光Next,西の光プレミアム,B-Fletsの自治体ファイバを
使っている版などで問題
RAでIPv6アドレスがついてくるが、IPv6インターネットにはでれない
・キャッシュDNSサーバ
最後の砦; ユーザが必要のないフォールバックを避ける
IPv6閉域網に接続したユーザ向けキャッシュDNSサーバ
・BINDでのAAAA filter設定
./configureのときに邪悪なオプション(--enable-filter-aaaa)が必要
これをしないと設定時に怒られます
filter-aaaa-on-v4 yes;
・BINDでのAAAA filterの挙動
ホスト名:AとAAAA→AAAAを応答しない
ホスト名:AAAAのみ→AAAAを応答する
BrokenなIPv6ユーザにfallbackするための技術、
AAAAのみが設定されている場合、応答した方がまだ繋がる可能性がある
と考えたらしい
→NTT NGNのサービスについてはAAAAのみがついているので影響はない
CacheからAuthoritativeにちょっとだけ問い合わせが増える
・対応の利点
コンテンツ事業者が安心してIPv6対応できる
アクセスできないという悪影響がなくなる
IPv6閉域網に接続したユーザで発生していた不要なIPv6->IPv4
フォールバックがなくなる
NTT NGN からRSTがかえってくると1秒でフォールバック
Windowsでは30秒ぐらい、200秒ぐらいのOSも
・対応の懸念点
IPv6閉域網に接続したユーザがインターネット側のAAAA
レコードを検索できなくなる
ISPが運用するキャッシュDNSが増える
AAAAを応答しないサーバ
応答するサーバ
Q: これを設定したISPはいつまでやっているの?
A: 状況が改善するまで。NGNがIPv6接続サービスを提供するか、IPv6サービスを
提供すればいい。
Q: DNSSEC で署名されている場合には AAAA を返す
IPv4アドレスベースでACLで表現できる
このプレフィックスのAAAAだけ答える、というオプションを作ることも可能だが、
ISC では開発費用が必要
Q: フィルタをするのではなく、応答する順番を変えるのではだめか
A: だめ。今時の端末は RFC 3484 で IPv6 を優先する。端末がAとAAAAを独立に
クエリを出す。パケットを出す順番とgetaddrinfoが返す順番は同じではない。
C: World IPv6 dayだけやるという話もあるが、その日うまくいけば、そのまま
ずっとやるという話もある
A: そのうちポリシーテーブルを修正するなどの対策案が公表される予定
Q: 副作用は?
A: ユーザがAAAAが見えなくなるだけ
Q: パフォーマンスペナルティは?
A: ペナルティはあまりない
Q: ACLは?
A: 行数による
■「重複をお許しください」ができるまで (JPRS 森下さん)
- 「重複をお許しください」とは
技術コミュニティ系のメーリングリストにマルチポスト
2週間に1通出している計算
DNSSEC関連のアナウンス(15通), BIND9の脆弱性(5通)
なぜいつも同じ書き出しなのか:過去メールの再利用
- 「重複をお許しください」ができるまで
BIND 9 の脆弱性
qmail/netqmailの512バイト問題
ISC からの "Advance Security Notification" (ASN)
セキュリティアドバイザリを先行して通知
ISC サポートサービスとして提供
一般よりは1週間ぐらい早い
2009年7月のDynamic Updateの脆弱性はすぐ出た
- ASN を分析
危険度(Severality, Exploitable)
対象: Versions Affected
すでにExploitがあるかどうかActive Exploits
- 詳細を分析
実装がわるいのか、プログラムが悪いのか、プログラムの構造が悪い
出来てしまうことはなにか
BINDを落とせる、毒入れされる、DNSSEC検証をパスする
- 文章の素案を作成
タイトル(緊急をいれるか)、推奨度など
構成を決める(概要、詳細など)
・中身の作成とレビュー
・動作の確認、追試(レビュー)
・アナウンス
ISCのWebを定期的にチェック
CVEやCERTのWebについてもチェック
・アフターフォロー
情報の広まり具合や対応状況のチェック
Twitter, セキュリティホールmemo
検索エンジン、ブログ、メディア
・作るに当たり気をつけていること
長いと読んでもらえないこともある
「概要」を読むだけで以下のことがわかるようにする
対象、何の不具合か、どういうことができてしまうのか、情報源、
危険性、どうする必要があるのか
「対策」には必要な対策について簡潔に記述
「詳細」は興味をおった人が技術的詳細は実際にできることの
詳細を読む場所にする
情報源や必要なパッチ
・ケーススタディ: qmailの512byte問題
基本的にBIND 9を踏襲
開発元の公式発表を受けたものではないため、情報源がない
技術的に中立に記述
・最後に
今後も必要に応じて出来るだけ迅速に「重複をお許しください」を
出す予定です
文章作成技術や広報技術に関するさまざまなノウハウを蓄積・共有
していければ
qmailの件がなぜいまいちなのか
・送り側が何年も設定を変えていないのにおかしくなる
→自分のせいだという認識が薄い
・受け側がDNSSECを入れた所だけがおかしくなく
→やっぱり相手が設定を間違えたに違いないと思われる
・SMTPセッションが張られる前にこける
→受け取り側でエラーが起こっていることがわからない
・エラーメッセージからは真の原因がわかりにくい
→deferral: CNAME_lookup_failed
・デフォルトでは一週間後に初めてエラーメールが戻る
→受け側でのDNSSEC導入後、しばらくしないと発覚しない
(開発元からパッチが出ていない)
Q: 実際仕事が増える人
A: 数名挙手
■Number of DNSSEC validators seen at JP (JPRS藤原さ)
DNSSECの普及率を調査
TTLが86400秒なので.JPを検証するDNSSEC KEYを1日に1回取りに来るはずだ
手法: packet capture と query log
- packet capture
55hour -約183万のリゾルバ中、3315のIPアドレスが DNSSEC の validation
- query log
a.dns.jpとg.dns.jp
Q: 地震以降にvalidatorが増えたというのは、自宅サーバがVPSに引っ越してい
る影響か?
C: 正月にも減っているの興味深い。
C: 大学も止る
■各ccTLDのDNSSECステータス地図をつくってみました
(BBT 大本さん)
最初はTwitterやWebサイトの情報収集でccTLDの動向をチェック
メールで定期digチェックした内容をアラート通知するスクリプトを作成
最初はGoogle Earthで作成。
kmlファイルの作成が大変
参考にしていたサイトで配布が停止
→Hello Worldでweb向け地図生成が出来るらしい
新しくできた国や地理関係がおかしい部分も修正
(マレーシアとシンガポールの位置が逆だった)
小さい島はDNSSEC対応が早い
小さい国はもともと記載されていない国もあった
http://www.ohmo.to/dnssec/maps/
■JANOG28のお知らせ
(NTTCom 吉村さん)
7/14(木)-15(金) @ 日本橋