Кратко

  • ZONE из RFC 1296 вёл список доменов и серверов, сначала задавал SOA, чтобы проверить авторитетность достигнутого сервера для домена, и лишь затем запрашивал AXFR. Под «хостом» понималась найденная в DNS группа [name(s), IP-address(es)], а не машина, прошедшая проверку прямого сетевого доступа.
  • Неразрешённые или оставленные после неудач передачи зон и хосты, которых не было в записях доменных серверов, уменьшали видимую таблицу. Случайные, неверно оформленные, неавторитетные и оставшиеся после переименований записи могли её увеличить. После ручного просмотра автор счёл избыток незначительным по сравнению с пропусками и назвал данные ZONE минимальным числом хостов, а не фактическим числом.

RFC 1296, Internet Growth (1981-1991) особенно полезен именно тем, что не скрывает время внутри числа. Чтобы получить ряд, ZONE должен был начать с известного списка, добраться до сервера по TCP, принять или отвергнуть свидетельство SOA, завершить или не завершить AXFR, сохранить некоторые типы записей, объединить имена и адреса и закончить обход. Наблюдения в такой цепи имеют разный возраст. Сбор, растянувшийся на неделю, не превращается в синхронный снимок оттого, что в итоге у него одна дата в таблице.

Это различие защищает не только календарную точность. Оно не позволяет считать опубликованную цифру доказательством прямой достижимости, полной регистрации или уже созданной непрерывной базы данных. Мемо отдельно описывает то, что ZONE делал, то, что ему мешало увидеть, и проект будущей архитектуры. Историческое чтение должно удержать эти три времени раздельно: выполненное измерение, известные пределы его охвата и ещё не реализованное предложение.

Сначала маршрут получения, потом число

Название ZONE расшифровывается как Zealot Of Name Edification. Программа была написана в 1986 году для перехода от Host Table к DNS. Первоначальная задумка состояла в том, чтобы пройти дерево DNS, построить из полученных данных Host Table и обслужить площадки, которые ещё не завершили переход. В этом качестве программа, по словам RFC, не использовалась; зато оказалась пригодна для статистики размера системы доменов и Интернета. Смена задачи не меняет природу материала: таблица, собранная для одной операционной потребности, остаётся таблицей того, что способ её сбора сумел получить.

ZONE хранил список доменов и их name servers, а также признак того, были ли сведения о домене успешно загружены хотя бы с одного из серверов. Из-за ещё одной ошибки BIND ему требовался начальный список доменов верхнего уровня и их серверов имён. Если домен ещё не был передан, программа по очереди пыталась связаться по TCP с сервером из списка. После соединения она сперва отправляла Start of Authority, SOA, чтобы удостовериться, что этот сервер авторитетен для запрошенного домена. Только после такого результата следовал AXFR с запросом всех resource records зоны.

Полученная NS-запись добавляла упомянутые домен и сервер в оставшуюся работу. Записи A, CNAME, HINFO и MX попадали в находившуюся в памяти таблицу сведений о хостах. Когда программа проходила весь список без новой информации, она записывала таблицу в формате HOSTS.TXT. Каждая стадия имеет узкий смысл. Ответ SOA служит основанием считать сервер авторитетным для конкретного вопроса. Завершённая передача подтверждает, что процесс получил записи. Таблица подтверждает, что к этим записям применено правило. Ни одна стадия не подтверждает, что конечный узел в ту же минуту доступен непосредственно из Интернета.

RFC определяет хост как группу [name(s), IP-address(es)], обнаруженную в DNS. Это нужно, чтобы не считать несколько имён или адресов одного хоста несколько раз. Правило не устанавливает физическую тождественность машины, её включённость, существование маршрута, доступность приложения или принадлежность к той популяции, о которой хочет говорить читатель. Нормализация снимает проблему повторного счёта, заданную исследователем; она не даёт объекту новые свойства.

У серии есть окно, а не единая секунда

Время прохода менялось. DNS был введён около 1984 года и почти четыре года добирался до полного внедрения в Интернете; за этот переходный период многие хосты уже перестали вноситься в Host Table. Ранние версии BIND имели серьёзные проблемы с функцией передачи зон, поэтому примерно до 1988 года ZONE не мог собирать полные DNS-данные. Длительность сбора выросла от часов до недели, а таблица приблизилась к 50 мегабайтам. В использовавшемся тогда режиме программа оставляла только имена хостов и IP-адреса, игнорировала данные протокола, сведения о хосте и MX, а статистику затем делала с помощью sort, uniq и grep.

Запуск на SRI происходил раз в три месяца.

Из этих деталей следует не претензия на худшую точность, а определение того, что именно можно утверждать. Неделя — это окно, в котором разные зоны и разные ответы увидены в разные моменты. Трёхмесячный ритм не является непрерывным реестром. Поле, отброшенное ради объёма, нельзя потом объявить наблюдённым. Изменение стартовой точки, задержки сети, состава отвечающих серверов, времени окончания передачи, фильтра полей или правила группировки способно изменить смысл ряда даже тогда, когда линия на диаграмме выглядит плавной.

Дата «1 января 1992» поэтому должна читаться как дата конкретного запуска и его отчётной точки, а не как магическая синхронизация всех объектов, которые слово Internet может включать. Она не переносит наблюдения из начала и конца длительной обходной процедуры в одну общую секунду. И она не говорит, что вне этой процедуры не происходило ничего, что имело бы отношение к реальному числу машин, имён или сетей.

Пропуски имели известное направление, но неизвестный размер

В RFC прямо указано, что некоторые Internet sites не позволяли передавать зоны со своих domain servers. После большого числа неудач ZONE прекращал попытку. В выполнении 1 января 1992 года не удалось передать примерно 800 из 17 000 доменов. Документ также исходит из того, что не все хосты Интернета были зарегистрированы у доменного сервера. Всё это отсутствует не потому, что алгоритм решил не считать уже полученную запись, а потому, что материал не дошёл до его таблицы.

Отсюда следует вывод, что статистика ZONE лежит ниже фактических количеств. Но направление смещения — не формула для неизвестного остатка. Мемо не сообщает число хостов за каждой запрещённой передачей; оно не говорит, что каждый хост без DNS-записи был доступен извне; оно не вычисляет, сколько следует прибавить. Его утверждение осторожнее: метод, который строит результат из удачно полученных зон, не может выдавать за наблюдённое то, что передать отказались, не сумели или вообще не внесли в источник.

Такое «минимум» — вывод о направлении доказательства при описанных условиях, а не неудавшийся итоговый подсчёт. Он сохраняет полезную асимметрию: пропущенное может уменьшить таблицу, хотя масштаб уменьшения неизвестен. Именно поэтому число нельзя ни отвергнуть как бесполезное, ни дополнить воображаемой поправкой и назвать полным.

Излишки тоже были частью метода

Уменьшение не было единственным источником ошибки. Ручной просмотр собранного материала обнаружил много случайных записей в DNS. Неверно сформатированные записи могли давать ложные записи серверов или хостов. Иногда сервер не был авторитетен для домена, к которому его относили. Целые домены могли быть переименованы, но старые записи сохранялись в переходный период; тогда каждый хост такого домена оказывался посчитан дважды. Это риски добавления и дублирования внутри уже наблюдённой части.

Автор не делает вид, что их нет. Он пишет, что ручная проверка показала незначительность этих дополнительных записей по сравнению с уже названными пропусками. Именно сопоставление двух направлений для данного материала позволило назвать данные ZONE минимальным числом хостов. Из него нельзя вывести правило, что любой современный или будущий обход DNS автоматически даёт нижнюю границу. В мемо зафиксированы программа, период, набор данных и профессиональная оценка; не универсальный закон о DNS.

Полезно отделять журнал происхождения от вывода. Журнал отвечает, какой домен пытались получить, какой сервер вызвали, был ли SOA принят, закончился ли AXFR, когда запись пришла и как её обработали. Вывод отвечает, что обозначает группа имён и адресов и как известные потери соотносятся с известными избытками. Старое имя в зоне не доказывает живую машину. Удаление повторов не раскрывает содержание недоступной зоны. Присутствие записи не заменяет опыт по достижимости.

DNS-имя не отвечает на вопрос о прямом доступе

Вопрос охвата в RFC не спрятан в технической детали. Нахождение хостовых записей в DNS не означает, что эти хосты доступны из Интернета напрямую. Компании могли держать mail gateways между Интернетом и своими локальными сетями и блокировать прямой доступ; одни объявляли все хосты, другие — только gateway. Какие из них следует включать в исследование размера Интернета? Передача ещё одной зоны не выбирает ответ.

Многие DNS-домены были только MX-записями для перенаправления почты на sites вне Интернета, например Usenet sites. Следует ли считать такие домены? Здесь видны разные объекты, которые часто склеивает один удобный термин: административный домен, почтовый маршрут, опубликованное имя, напрямую доступный узел и определённая популяция. Они могут пересекаться, но не становятся тождественными оттого, что их записи лежат в одном источнике.

У каждого слоя доказательства свой предел. Ответ DNS подтверждает опубликованную запись. Успешный AXFR подтверждает, что процесс получил материал зоны. Правило группировки подтверждает способ обработки. Чтобы утверждать прямую доступность, институциональную принадлежность, личность или полный охват, нужен иной критерий, другое наблюдение или определяющий орган. У восходящей временной серии нет права незаметно приносить с собой эти признаки.

Предложенное будущее не надо переписывать в прошедшее

Раздел о будущих вопросах описывает ZONE на DECsystem-20, написанный на assembler. Объём данных приблизился к пределам адресного пространства и к тому, что оборудование могло устойчиво перенести. Прежде чем записать данные, программа держала их в памяти, чтобы связать aliases хоста с его canonical names; alias мог находиться в другом домене, чем официальное имя, и это затрудняло более простой подход. Автор предлагает другую архитектуру: хранить данные на диске, выполнять несколько передач параллельно и непрерывно работать в цикле от недель до месяца, обновляя локальную базу статистикой по доменам.

Это проект, а не отчёт о внедрённой замене. RFC не сообщает, что такая непрерывная локальная база уже работала, и не утверждает, что предложенная конструкция создала полный учёт. Параллельные передачи могли бы сократить длительность обхода. Диск мог бы уменьшить потери после сбоя. Более частый цикл мог бы сделать некоторые наблюдения свежее. Ни одно улучшение не отменяет разницу между DNS-записью и доступным хостом, между группой имён и идентичностью, между видимой нижней границей и общей популяцией.

Эта граница особенно важна для истории инфраструктуры. Проектировщик часто говорит одновременно о нынешнем ограничении и о способе его уменьшить. Поздний читатель может ошибочно взять второе за первое: прочитать предложение как свершившийся факт и приписать исходной цифре полноту, которой автор не обещал. RFC 1296, напротив, оставляет будущему его время.

Стоимость сбора также ограничивает смысл серии

Скачивание информации из каждого домена создавало сетевой трафик и нагрузку на CPU каждого достигнутого сервера. Поэтому RFC предлагает, чтобы организованное усилие запускало один сборщик через регулярные интервалы, избегая множества повторяющих друг друга сборщиков. Это предложение о координации и о распределённой цене наблюдения. Оно не доказывает неограниченное право запрашивать зоны и не делает одного оператора владельцем определения измеряемой группы.

Даже небольшая программа задаёт важные узлы управления: исходный список, число повторов до отказа, классы хранимых записей, порядок обхода, периодичность и язык публикации результата. Операторы решают, разрешать ли передачу, и несут часть нагрузки. Исследователь выбирает группировку. Читатель решает, станет ли ограниченная методикой цифра кратким обозначением охвата, значимости, легитимности или размера рынка. Слово «счёт» не устраняет эти решения.

Источники и пределы доказательств

Единственный источник — RFC 1296. Он подтверждает informational-статус января 1992 года, историю Host Table и ZONE, последовательность SOA/AXFR, типы записей, определение хоста, неудачи передач, остаточные записи, вывод о нижней границе, вопросы охвата, числа января 1992 года, стоимость сбора и будущий архитектурный проект. Он не подтверждает нынешнюю DNS-популяцию, живую передачу AXFR, современное поведение BIND, действующую политику перечисления зон, доступность конкретного хоста, принадлежность организации, безопасность, внедрение предложенного сборщика или более поздний результат.