安全な（共用）DNSサービスの提供
- 2. 対象
● 共用の権威DNSサーバ 運用者
＝ユーザのゾーンを権威ありで配信する
DNSサーバを運用している人
● その利用者
● セカンダリやら実装のセキュア化やらは対象外
2
- 3. 対象
のうち、
● 自分のような自称野良サーバ管理人
のスライドなんぞを読んでみる勇気ある方々
● さくらのDNSで6月に起きた問題をみて、
『つまり…どういうことだってばよ？』
と思った方々
（つまり対象は誰もいない！！！ほんと自分用）
3
- 4. ユーザとクエリの種類
エンドユーザ・スタブリゾルバ
再帰クエリ
自分は委任関係を調べてません。
そちらの言うことを信頼するので 使いたいのは
そっちで全部一切合切 キャッシュとリゾルバ
調べて教えてください オススメ情報も欲しいかも
（フル）リゾルバ・キャッシュサーバ
非再帰クエリ
自分は（たぶん）委任関係を
（自前で）調べています。
使いたいのは
知ってる限りのことを 委任ゾーンの情報だけ
教えてくれればそれでいいです。 追加情報は要らん
4
- 5. DNSサーバの簡略構造
回答を生成
権威レコード する際の
+NS+グルー 優先度は
↑上から
再帰クエリ ↓下の順
レスポンス
キャッシュ
非再帰クエリ
生成
The
再帰クエリ Intern
内蔵リゾルバ 非再帰クエリ
5
- 6. 理想的な キャッシュサーバ
呼び方色々
● ISPのDNS
● リゾルバ
再 委任関係は持たない
帰
クエ
リ （192.168.1.1は僕のサーバです！
キャッシュ 勝手に委任しないでください！）
レスポンス
生成
実際には権威レコードあり
● Localhostなど
内蔵リゾルバ 非
再
帰
クエ
リ
6
- 7. 理想的な コンテンツサーバ
委任されたゾーンのデータ
● 権威レコード
● NSレコード＋グルー
非 だけを返せるなら十分。
再
帰
クエ
リ でも現実には
委任されていない追加情報も返すことが多い。
レスポンス 権威レコード そのためのキャッシュ＋リゾルバ実装
生成 +NS+グルー
● 未知のドメインなら推奨DNSサーバを
● NS/MX対応のAレコード追加
● CNAMEの変換
……ポイズニング対策で捨ててるのに
リゾルバは自前でチェックできる。
7
- 9. キャッシュに悪意が入ると？
悪意の（検閲）レコード
権威レコード
=コンテンツ google.co.jp. IN CNAME evil.example.jp.
キャッシュ・リゾルバとして
使っているユーザ
生成 ×
レスポンス
キャッシュ
が影響を受ける
キャッシュ汚染より恒久的
正しく委任されてないので知らない人は
×
関知出来ない
内蔵リゾルバ 使いたいのは
リゾルバと
キャッシュだけなのに！ 9
- 10. 委任されていない権威レコード？
権威レコード
+NS+グルー ≠ 委任されている
正しいレコード
間違って”権威”が設定される理由
親のNSレコードが消えてる
設定ファイル管理スクリプトのバグ
共用DNSの不正利用
ゾーン同期転送の改竄
10
……いろいろ考えられる
- 11. 分割しろ
キャッシュサーバ コンテンツサーバ
再帰あり 再帰なし
レスポンス 権威レコード
生成 +NS+グルー
キャッシュ
再帰クエリ レスポンス
生成
リゾルバ 非再帰クエリ
ルートから
親ゾーンまで
権威レコード コンテンツにもし悪意が入っても 11
+NS+グルー 正しい委任関係が無い=誰も見ない
- 12. Viewで内部分割したよ（BIND9）
再 View機能で内部分割・フィルタ出来るようになりました!
帰 （match-recursive-only）
非 クエ
再 リ
帰
クエ
リ
フィルタ
再帰なし
権威レコード
再帰あり +NS+グルー
レスポンス レスポンス
生成 キャッシュA 生成 キャッシュB
リゾルバ リゾルバ
12
- 13. Viewで内部分割したよ（BIND9）
再
帰
個別に禁止も出来る！
非 クエ recursion no; additional-from-auth no;
再 リ
帰 additional-from-cache no;
クエ
リ
フィルタ
再帰なし
権威レコード
再帰あり +NS+グルー
レスポンス レスポンス View毎に
生成 キャッシュA 生成 キャッシュからの
応答禁止
リゾルバ動作禁止
を設定可能
内蔵リゾルバ
13
- 15. 本当にそれ委任ですか？
DNSの最長一致原則
＋
実装による権威レコードの優先度
親ゾーンの設定ファイルにNSレコードがなく
（親は否定応答する権威有り）ても
同じサーバにサブゾーン（権威有り）
があれば有効
15
- 16. ゾーンファイルは踊る
ひとつのサーバに……
あくまでzone”設定ファイル”の
$ORIGIN example.com.
@ IN SOA (略) 解釈は実装依存
@ IN NS dns.example.jp.
; subにNSレコードは無し
● ゾーン毎にチェックして
; 否定応答は権威有り 親子の矛盾としてエラー？
＋
$ORIGIN sub.example.com. ● レコードに変換してからチェック
@ IN SOA (略) 実質両方にNSレコードがあるか
らOK？
@ IN NS dns.example.jp.
; ゾーンルートなので権威有り
; どっちが優先されるの？ 外からは区別が付かない
16
- 18. 考慮すべきサービス範囲
● 共用DNSを管理する全てのサービス
● 共有サーバ管理（cPanel, Plesk, 独自…）
つまり独自ドメイン対応サービス＝XaaSの多く
外からDNSの管理ポリシーをチェックする方法は？
……攻撃成功事例を見つけるか、複数アカウントで自分自身を攻
撃してみるしかなさそう
基本 中の人がチェックして説明するしかない
18
- 20. 受け入れドメインの所有確認は？
● レジストラが本業なので全員分把握してる
● Whoisに載ってるメールアドレス
● 親ゾーンのNSレコード
● 登録済みゾーンと矛盾しなければ
● もし不正や間違ってたら消す
20
- 21. 現状は？
● 既存ゾーンのサブゾーンの不正取得は？
● アカウント・ゾーンの先取りは？
●
キャッシュと権威の分離は？
● ゾーンルートのNSレコードは設定可能？
● （兼・浸透いうな不浸透問題）
管理ポリシーをユーザに説明できますか？
21
- 23. 提案:受付時にNSレコードを変更させる
ランダムなNS名を指定して変更してもらう
＝DNS経由でチャレンジ・レスポンス認証が出来る
● 虚偽のゾーン受入申請を全て排除できる
● NSレコードが消えたら（委任も消えるので）
事実上、アカウントと紐付けが失効する
● これはルートからtraceすれば明示的に確認できる
23
- 24. 導入は難しいけれど
● 必然性を説明しづらい
● UI実装とユーザサポートのコスト
● 増加するAレコードクエリによる負荷上昇
● 面倒くささ（priceless)
でも所有者チェックは何らかの方法でやらないと……
● キャッシュ分離が前提
●
ドメイン新規取得時など
まだ委任されていない権威レコードが必要
24
- 26. 幽霊ドメインはどうする？
● 権威サーバからゾーンを消さずに
親ゾーンのNSレコードだけ抹消or変更されると？
● キャッシュ上の既に変更されたはずのNSレコードが
元権威DNSからの返答で更新され続ける
＝幽霊ドメイン問題 (≒浸透いうな不浸透問題）
世界中のキャッシュサーバのフィックスに期待する?
共有DNS管理者側でこれを検出するには？
26
- 28. 登録時にチェックしてないよ！
何……だと？
● ルートから順に委任が正しいかチェック
→ 権威（と思っていた）DNSサーバに委任されてない？
親ゾーンのTTLだけ待って消す
● もし、親ゾーンとサブゾーンが同居していたら？
→ 親ゾーンの利用者が意図して委任しているか
個別に確かめる （実装依存なので）
28
- 29. 主張
● キャッシュと権威コンテンツは分ける
●
ドメイン受入は委任チェック＝所有権チェックを
● 定期的に委任されていないゾーンは消す
29
