RIG#1-2

2019年09月24日に開催されたRIG第1回勉強会，講義1で使用されたスライドです．DNSの概要や問題点の説明，Internet Governanceの観点から見たDNSの運用について簡単に解説しています．

Transcript

1. DNSとそのガバナンス RIG #1-2 (9/24/2019 1915-1940 JST) 慶應義塾大学総合政策学部2年 大谷 亘 a.k.a. alt
2. 自己紹介・注意 alt • 慶應義塾大学総合政策学部2年 • スタートアップ企業 バックエンドエンジニア • アマチュア無線局JJ1LFC ※特筆のない限り発表時点での情報をもとに作成 ※個人的な感想も交じる
3. DNSとは • Domain Name System • ドメイン名<==>IPアドレスを相互に変換(名前解決)する仕組み • RFC1035 UDP53番ポートを使用する • インターネット上の多くのサービス・仕組みで利用 • ツリー構造を持つ
4. DNSサーバ • Authoritative Server (権威サーバ) ◦ IPアドレス<==>ドメイン名の変換情報など (records)のはいった表(table)を持つ ◦ リクエストに対し、全部ないし一部の要件を満たす答えを返す • Caching Resolver (キャッシュサーバ・リゾルバ) ◦ クライアントからのリクエストに応じ、いろいろな権威サーバから答え (の断片)を集めて、完全な正 解をクライアントに返す ◦ 一度聞いた答えはいちいち権威サーバに聞かずに、一定期間 (TTL)内部にためておき(cache)、も う一度聞かれたらすぐに返す ◦ 一般に「DNSサーバ」といったらこっち
5. DNSレコード • A: IPv4アドレス • AAAA: IPv6アドレス • NS: 権威サーバ • SOA: ゾーン情報 • CNAME: 参照するドメイン(ホスト)名 • MX: メールサーバ • TXT: 任意の文字列 etc...
6. root .keio .jp .com .net .ac .co .sfc .u-tokyo .sfcrig .google .amazon .lib リゾルバ ユーザ (クライアント) www.sfc.keio.ac.jpに行きたい！ 1.ユーザがリゾルバに recursive queryを投げる 2.リゾルバは自身のcache tableを見 て、存在すればその値を answerとし て返す 3.なければrootにiterative queryとし て投げる 4.rootは答えの一部を知っていそうな サーバをreferralとして答える 5.リゾルバはそのreferralに..... … 6.完全な答えを知っているサーバが answerとしてリゾルバに答える 7.リゾルバは答えをanswerとして ユーザに返す 1 2/7 3 4 ツリー構造と名前解決 6 5
7. rootサーバ • (基本的に)世界中のクエリすべてが通る ◦ すべてがダウンするとほぼ「インターネットが壊れた」状態に • 物理的・地理的(・政治的?)に冗長化 • anycastを用いて複数のクラスタを運用 • 12団体により13(a-m)系統1,017台が運用中 • m-rootは日本の学術プロジェクト「WIDE Project」とJPRSの共同運用
8. サーバ 管理者 国 IPv4 IPv6 サイト数 a-root Verisign アメリカ 198.41.0.4 2001:503:ba3e::2:30 28 b-root 南カリフォルニア大学 アメリカ 199.9.14.201 2001:500:200::b 3 c-root Cogent アメリカ 192.33.4.12 2001:500:2::c 10 d-root メリーランド大学 アメリカ 199.7.91.13 2001:500:2d::d 155 e-root NASA アメリカ 192.203.230.10 2001:500:a8::e 250 f-root ISC アメリカ 192.5.5.241 2001:500:2f::f 237 g-root 国防総省 アメリカ 192.112.36.4 2001:500:12::d0d 6 h-root 陸軍研究所 アメリカ 192.97.190.53 2001:500:1::53 2 i-root Netnod スウェーデン 192.36.148.17 2001:7fe::53 69 j-root Verisign アメリカ 192.58.128.30 2001:503:c27::2:30 164 k-root RIPE NCC オランダ 193.0.14.129 2001:7fd::1 70 l-root ICANN アメリカ 199.7.83.42 2001:500:9f::42 168 m-root WIDE/JPRS 日本 202.12.27.33 2001:dc3::35 9
9. 代表的な脆弱性・問題 • rootサーバへの攻撃 ◦ anycastによる分散や運用で対処 • 権威サーバのなりすまし(spoofing) ◦ kaminsky attack ◦ DNSSECなどで解決方向に • DNSブロッキング • rootサーバの維持
10. DNS Cache Poisoning • DNSのCacheを書き換えることで、本来と違うサーバに誘導する攻撃 • クエリと応答の対応に使うTXIDが16bitしかない • クエリしたあとに書き換えたい偽の応答をランダムなTXIDとともに割り込ませる • 正規のサーバからの返答と勘違いしてしまう
11. Kaminsky Attack • 2008年に考案 • 標的ドメインのランダムなサブドメイン(存在は問わない)を大量にクエリ • UDPは送信元を容易に偽装できるためいくらでも打てる • クエリされた側は毎回知らない値を聞かれるので毎回問い合わせる • ランダムなTXIDをぶつけ続ければそのうち当たる • パッシブにpoisoningの機会を待たず自分からアクティブにクエリする • 「数撃ちゃ当たる」戦法
12. DNSSEC • DNS Security Extension • RFC4035 • 権威サーバ同士で証明書のチェーンを構成する • 上位のサーバが下位のサーバを署名、クエリへの返答時に下位サーバの公開鍵 に電子署名をして渡す • 下位サーバからの返答が正答なものか、公開鍵を用いて検証する • これを繰り返すと、rootさえ信頼できればすべての答えを信頼できる • 上位サーバすべてが対応している必要がある
13. DNSSEC -rootサーバ • じゃあrootサーバはどうやって信用する? • Root Zone Trust Anchor(ZSK: Zone Signing Key)が複数人によって文字通り「署 名」されている • https://www.iana.org/dnssec/files • そのZSKはどうやって信用する? • ZSKはKSK(Key Signing Key)によって署名される • KSKはSigning Ceremony によって数カ月おきに鍵ペアが作成される • https://www.iana.org/dnssec/ceremonies • 実は人間の署名・確認・信頼でインターネットの安全が保たれている • https://www.jnsa.org/seminar/seckey/101122seckey/minda.pdf
14. DNSブロッキング • 政治的な理由などで一部のドメインのレコードを削除/変更する or リゾルバの時点で値を返さない/変更する • 少し前に日本で話題になった(漫画村問題) ◦ ちょうど今日運営者が逮捕されましたね • 日本では既に児童ポルノに対し実施 • Internet Governanceに国政を持ち込んでいいのか? • 誰が従うのか? • 1人でも従わなかったら意味がない ◦ 従わないリゾルバ/権威サーバがあればそこを積極的に利用すればいい ◦ リゾルバなら自分で建てられるね →根本的な解決にならない • http://www.wide.ad.jp/News/2018/20180912.html
15. rootサーバの維持 • 誰が運用している? ◦ 研究者団体、私企業、国家 • 誰がお金を出す? • なんで運営する? ◦ もともとは研究者の嗜み • 本当にその基盤に任せられる? ◦ 今やインターネットは最もクリティカルな社会インフラ • 誰になら任せられる? ◦ ただ「お金も技術もあります !」という人に何も考えずお願いしていいの ?
16. 出典・参照 • https://root-servers.org • https://www.ietf.org/rfc/rfc1035.txt • https://www.wide.ad.jp/News/2018/20180912.html • https://www.nic.ad.jp/ja/newsletter/No45/0800.html • https://www.iana.org/dnssec/files • https://www.iana.org/dnssec/ceremonies • https://www.jnsa.org/seminar/seckey/101122seckey/minda.pdf ※最終参照はすべて2019/09/24 16:00