Describe TICメモ here.
== TICメモ ==
  2005-09-23

対象：DNS運用担当者

「仕様、実装、運用、人、組織、社会」のそれぞれの問題をあげてみました。

DNS の信頼性の調査
  Survey of DNS server administration status

DNS とは
  Domain Name System
    Internet 接続は IP アドレスを使って行われる。
    IP アドレスの代わりにドメイン名というものを利用して、
    便宜をはかっている。
    
    Basic function (directory service)
    �bind "Domain Name" and "IP address"
    
  階層構造をした分散データベースである。
    hierarchical distributed data base
    administered by each domain operators
  
  設計段階では悪用はされないという前提であったために、
  安全性は低い。(UDP を使うなど DoS にも弱い、偽造も簡単)
  
ソフトウェア
  BIND history (bug history)
  
コンテンツサーバとキャッシュサーバ
  情報を提供するための DNS サーバはコンテンツサーバと呼ばれる。
  情報検索はキャッシュサーバあるいは proxy サーバで行われる。
  
  歴史的に両者を兼る実装(BIND) が使われてきたために安全性に問題がある。
   
DNS cache poisoning
  キャッシュサーバに偽りの情報を注入する手段が存在する。
  これを避ける方法もあるが、使っているところは少ない。
  コンテンツサーバと兼用のサーバでは被害を拡大する。(recursion yes)
  
ドメインの委譲
  分散管理のためにサブドメインに対して権限委譲が行われるが
  その部分では誤り(設定ミス)が起きやすい。
  
  設定時に正しくとも、変更時に誤りが入ることも多い。(運用面での不備)
    サーバ名の変更、IP アドレス の変更など
  
  Domain hijacking と visa.co.jp 問題
     registering incorrect name (e.g. typo)
     using expired domain name
     non-working DNS server
   存在しないドメインを参照する DNS NS resource record  
   jp レジストリによる強制削除(pruning)が開始された (2006.1)
   (ひとつの回避策は NS サーバ名に内部名を使うことである。)
   phishing was easy

調査 (DNS survey)
  Collection of domain names
  ドメイン名の収集 12 万個の jp ドメイン名を集めた。
  これらドメインに対して、
  コンテンツサーバ(NS レコード)を jp サーバから取り出した。
  Japan Resistry (JP DNS server)
    
  1. 登録されたサーバが DNS コンテンツサーバとして動作しているか。
     registered names in Japanese domain resistry
     多数観察された。 (authoritative server)
     返事は一致するか。
     Child and Parent should send same answer
     
  2. 内部名を使っているか (in-bailiwick servers)
    (1) 内部名を持つドメインは    20,000  domain with in-bailiwick server
    (2) 内部名だけをもつドメインは 5,000
    (3) 外部名だけをもつドメインは 90,000
    
  3. キャッシュサーバと兼用になっているか。
    問合せを行い、recursion availble flag が on になっているかを調べる。
    80 % 以上が recursion yes (つまり、キャッシュサーバを兼用) であった。
    
提言
  いまさらながら、 DJB が 7 年前から書いていることであるが、
  以下の三つが重要であることが分った。
  (1) 登録したサーバはきちんと動かす
  (2) コンテンツサーバとキャッシュサーバの分離
  (3) サーバには内部名をつける
  これ以外の項目はその後の話である。(bad data)

Reference:
  RFC 1034,1035, 19xx
  ...
  www.e-ontap.com (public alert)

----------------------------------------------------------------------------
仕様: 
  集中管理が必要な構造とそれを利用する組織
  スケーラブルでない構造(技術的には解決可能だが)
  UDP を使うことによる問題 (長さ制限、spoofing)
  レコード値に名前を使ったことによる不都合：不整合、グルーの必要性
  レコードの内容を保証する手段の欠如(現状)
  
実装：
  BIND 5, 8 のセキュリティホール
  設定ファイルの複雑さ

運用：
  lame delegation, TTL, CNAME など仕様の不良からくる濫用は探す必要もないくらい
  visa.co.jp からみの話を解説するだけでも、30分では足りない

人: 
  まともな管理者がいない(待遇が悪すぎる)
  管理者を養成しているところもみあたらない。

組織:
  仕様の不良を改善する様子が見られない
  ICANN, JPNIC, JPRS など利権を握って離さない構造を許す状態

社会:
  DNS の重要性(危険性)を自覚していない
  自分達がどういう状態にいるのか、分っていない。
   
> 討論というより、随時質問という形の方がいいのでは。
> (どうせ、討論にはならないだろう、という気持があるので。)