要約

  • RFC 1296 の ZONE は、ドメインとサーバの一覧を持ち、接続したサーバが対象ドメインに権威を持つことを SOA で確かめてから AXFR を要求した。研究における host は DNS から発見した [name(s), IP-address(es)] のまとまりであり、直接到達可能かどうかの試験ではなかった。
  • ゾーン転送の拒否・失敗と DNS に登録されない host は収集を小さくしうる。形式不良の項目、非権威的なサーバ、名称変更後も残った古い項目は余分な記録や二重計上を生みうる。手作業の走査を踏まえ、文書は ZONE の値を実数ではなく host 数の下限と呼んだ。

RFC 1296, Internet Growth (1981-1991) は、Internet の成長を一つの数に圧縮する前に、数えられる対象を分けている。ここで重要なのは 727,000 という表の値ではない。何が観測され、何が観測されず、どの規則でレコードを一つの host にまとめ、誤差の向きについてどこまで言えるかを、値の外に追い出さなかったことである。DNS の木を歩けることと、Internet という集合を定義し終えたことは別の行為だった。

ZONE は Zealot Of Name Edification の略である。1986 年に、host table から DNS への移行のために書かれた。DNS の木を歩いて得た情報から host table を作り、まだ DNS へ移っていないサイトに使えるはずだった。実際にはそのためには使われず、ドメインシステムと Internet の規模について統計を集める用途が見いだされた。この用途の変更を、完全性の証明にしてはならない。レコードを表にできる仕組みは、すべての機械、すべての接続、すべての構成員を見た仕組みになるわけではない。

SOA の確認は到達試験ではない

ZONE の手順は、名前を検索結果から並べるだけのものではなかった。ドメインとそのサーバの一覧を保持し、あるサーバから情報を正常に読み込めたかを示す印を持った。BIND の別の問題のため、最初にすべてのトップレベルドメインと name server の一覧を与えなければならなかった。まだ転送できていないドメインについては、一覧を巡り、そのドメインのサーバの一つに TCP で接続しようとした。接続できると、まず Start of Authority、SOA の問い合わせを送り、要求したドメインについてそのサーバが authoritative かを確かめた。そうであれば AXFR を送り、ゾーンの resource record 全体を求めた。

NS を受け取ると、参照されたドメインとサーバを次の処理対象に加えた。A、CNAME、HINFO、MX の record を受け取ると、メモリ中の host information table に加えた。全リストを巡っても新しい情報が得られなくなった時点でプログラムは終わり、HOSTS.TXT 形式のファイルを出力した。ここには別々の出来事がある。SOA の答えは、その時点で収集器がこのドメインについてそのサーバに問う根拠を得たという出来事である。AXFR の完了は、その収集器があるレコードを受け取った出来事である。表の行は、受け取ったものに規則を当てた結果である。

どの出来事も、次の強い主張を自動では支えない。authoritative と確認されたサーバが答えたからといって、ゾーン中のすべての記述が正しいとは示されない。AXFR がレコードを返したからといって、その背後の host が Internet から直接到達できるとは示されない。レコードを一つのまとまりにしたからといって、それが一台の物理機械、特定の組織、または一つのサービスを表すとは示されない。観測されたのはレコードであり、到達可能性や所属や全体数は別の証拠を要する。

RFC 1296 は研究上の host を [name(s), IP-address(es)] の grouping と定義した。複数の名前やアドレスを持つ host を何度も数えないためである。だが文書は、この定義が直接アクセスの可否を考慮しないと明記する。これは集計の単位をそろえる規則であって、機械が稼働していること、経路が開いていること、名前が安定した実体を指すことを判定する規則ではない。定義があることと、定義外の性質を証明できることを混同してはいけない。

見えない部分には向きがあり、量はなかった

ZONE の下限という判断は、まず取得できなかった情報から来る。一部の Internet site は domain server の zone transfer を許さなかった。ZONE は失敗が多すぎるドメインを最終的に諦めた。1992 年 1 月 1 日の実行では、17,000 の domain のうち約 800 が transfer できなかった。さらに、Internet のすべての host が domain server に登録されているわけではないと仮定している。どちらも、方法が数えられたかもしれない record を表に入れられない理由である。RFC はこれらが収集した統計を実際の量より低くすると述べる。

ここで「低い」は、欠けた部分の大きさを知ったという意味ではない。転送できなかったドメイン一つに何台の host があったか、DNS にない host がどの程度直接到達可能だったかを、RFC は数えていない。それでも、成功した転送から得た DNS record を数える方法は、拒否されたもの、失敗したもの、そもそも資料源にないものを見えたものに変えられない。下限という語は、既知の欠落の向きを保存するための語であって、見えない分への仮の補正値ではない。

収集方法の履歴も、単一時点の国勢調査という読み方を妨げる。DNS は 1984 年ごろ導入され、Internet で完全に実装されるまでほぼ四年かかった。そのころには多くの host が古い Host Table に登録されなくなっていた。初期の BIND は zone transfer に重大な問題があり、ZONE が完全な DNS data を集められるのはおよそ 1988 年以降だった。収集時間は数時間から一週間に増え、生成する table はまもなく 50 MB に達した。当時の mode では host name と IP address だけを集め、protocol、host information、MX record を無視し、sort、uniq、grep などで統計を作った。SRI では三か月ごとに実行された。

一週間に及ぶ walk は、全 record を同じ瞬間に見た写真ではない。三か月ごとの run は常時の在庫表でもない。量を減らすために捨てた field は、あとから見たものとして引用できない。総数の意味は、開始一覧、観測期間、応答した server、完了した transfer、保持した record class、grouping rule に依存する。方法は数字の脚注ではなく、数字の内容そのものである。

余分な record は欠けた観測を埋めなかった

RFC 1296 は逆方向の誤差も隠していない。収集データを手で見たところ、DNS には多くの random entry があった。形式が正しくない entry は bogus server または host record を生みうる。ある server が listed domain に authoritative でないこともある。ドメイン全体が rename され、その古い entry が transition period のために残されると、ドメイン中の各 host が二度数えられうる。これらは表の中に余分な観測や重複を加え、値を高くする方向に働く。

文書の結論は、その危険を消してから下限と呼んだのではない。manual scanning により、追加の entry は前に述べた missing entry に比べて重要でないと判断された。だから ZONE data は actual figure ではなく minimum number of Internet hosts と見ることができる、と述べる。これは DNS walk が常に過小評価するという一般法則ではない。この program、この資料、この review について、欠落と余分の関係を比較した著者の限定的な判断である。

ここでは二つの仕事を分ける必要がある。一つは観測の帳簿を残す仕事である。どの domain を試し、どの server に接続し、SOA をどう確認し、AXFR がどう終わり、どの record をいつ受け取ったか。もう一つは帳簿を解釈する仕事である。record が研究対象をどう代表するか、missing と duplication の配置がどんな結論を許すか。sort や uniq は決めた規則に従って複数の name と address を整理できる。しかし、失敗した transfer の後ろに何台あったか、古い名前がまだ同じ host を指すか、名前の address が接続を受けるかを決めることはできない。

DNS にあることは Internet から届くことではない

RFC は、host と domain を数える難しさは Internet 自体の定義にあると明記する。DNS で host entry を見つけても、その host が Internet から reachable とは限らない。会社は Internet と local net の間に mail gateway を置き、direct access を許さないことがある。それでも全 host を広告する場合も、gateway だけを広告する場合もある。どちらを数えるのか。また DNS の domain の中には、Usenet のような off-Internet site のための mail-forwarding、すなわち MX entry だけのものがある。これを Internet size study に入れるのか。

これは追加の query で直る空欄ではなく、対象の定義の選択である。DNS の答えは、ある record が返ったという主張を支えられる。完了した AXFR は、collector がある zone record を得たという主張を支えられる。grouping rule は、table が double count をどう避けたかを支えられる。direct reachability、組織の所属、identity、総人口を言うには、別の定義、観測、authority が必要である。時系列が滑らかに並んでいても、そこから強い属性は生まれない。

すべての domain 情報を download することには cost もあった。大量の network traffic を生み、contact する各 domain server に CPU load を加える。RFC は multiple collector の問題を避けるため、organized effort が regular interval で一つの program を動かすことを考えてもよいと提案する。これは measurement の調整に関する提案であり、誰かに無制限の走査権や集合を一人で定義する権利があるという証拠ではない。

新しい設計案は現在の完成を意味しない

Future Issues で、文書は ZONE が assembler で書かれ DECsystem-20 上で走り、DEC-20 の address space と hardware の限界に近づいていると述べる。complete record を dump する前に nickname と official name を対応させるため、すべての data を in core に集めていた。nickname が official name と別の domain にあることもあり、単純な方式を難しくした。著者は、disk に data を置き、複数の zone transfer を parallel にし、数週から一か月の cycle で domain ごとの統計を更新する新しい architecture を提案する。

これは将来の設計であり、置換実装が作られたこと、continuous database が存在したこと、その後の数が完全になったことの証拠ではない。より頻繁な collection は観測の古さを小さくしうる。parallel transfer は walk の経過時間を短くしうる。disk は crash の損失を減らしうる。だが record と reachable host、name/address grouping と安定した identity、observed lower bound と total population の間の違いを消すものではない。RFC は道具の改善を考えながら、この差を残している。

出典と証拠の限界

唯一の出典は RFC 1296 である。これは 1992 年 1 月の Informational status、Host Table と ZONE data、SOA/AXFR の順序、record type、host grouping、transfer failure、残留 entry、下限という結論、scope の問い、1992 年 1 月の値、collection cost、将来 architecture の提案を支える。現在の DNS population、live AXFR、現代の BIND の性質、現在の enumeration policy、特定 host の reachability、組織の所属、安全性、代替 collector の配備、後の outcome を証明しない。