RIG#1-2

74dc690cab435bd58fe785cc72218ca4?s=47 RIG
September 24, 2019

 RIG#1-2

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

74dc690cab435bd58fe785cc72218ca4?s=128

RIG

September 24, 2019
Tweet

Transcript

  1. 3.
  2. 4.

    DNSサーバ • Authoritative Server (権威サーバ) ◦ IPアドレス<==>ドメイン名の変換情報など (records)のはいった表(table)を持つ ◦ リクエストに対し、全部ないし一部の要件を満たす答えを返す

    • Caching Resolver (キャッシュサーバ・リゾルバ) ◦ クライアントからのリクエストに応じ、いろいろな権威サーバから答え (の断片)を集めて、完全な正 解をクライアントに返す ◦ 一度聞いた答えはいちいち権威サーバに聞かずに、一定期間 (TTL)内部にためておき(cache)、も う一度聞かれたらすぐに返す ◦ 一般に「DNSサーバ」といったらこっち
  3. 5.

    DNSレコード • A: IPv4アドレス • AAAA: IPv6アドレス • NS: 権威サーバ

    • SOA: ゾーン情報 • CNAME: 参照するドメイン(ホスト)名 • MX: メールサーバ • TXT: 任意の文字列 etc...
  4. 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
  5. 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
  6. 11.
  7. 12.

    DNSSEC • DNS Security Extension • RFC4035 • 権威サーバ同士で証明書のチェーンを構成する •

    上位のサーバが下位のサーバを署名、クエリへの返答時に下位サーバの公開鍵 に電子署名をして渡す • 下位サーバからの返答が正答なものか、公開鍵を用いて検証する • これを繰り返すと、rootさえ信頼できればすべての答えを信頼できる • 上位サーバすべてが対応している必要がある
  8. 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
  9. 14.

    DNSブロッキング • 政治的な理由などで一部のドメインのレコードを削除/変更する or リゾルバの時点で値を返さない/変更する • 少し前に日本で話題になった(漫画村問題) ◦ ちょうど今日運営者が逮捕されましたね •

    日本では既に児童ポルノに対し実施 • Internet Governanceに国政を持ち込んでいいのか? • 誰が従うのか? • 1人でも従わなかったら意味がない ◦ 従わないリゾルバ/権威サーバがあればそこを積極的に利用すればいい ◦ リゾルバなら自分で建てられるね →根本的な解決にならない • http://www.wide.ad.jp/News/2018/20180912.html
  10. 15.

    rootサーバの維持 • 誰が運用している? ◦ 研究者団体、私企業、国家 • 誰がお金を出す? • なんで運営する? ◦

    もともとは研究者の嗜み • 本当にその基盤に任せられる? ◦ 今やインターネットは最もクリティカルな社会インフラ • 誰になら任せられる? ◦ ただ「お金も技術もあります !」という人に何も考えずお願いしていいの ?
  11. 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