Кратко

  • Draft 2 от 22 ноября 2017 года сохранил ограниченный предмет Draft 1: обратные зоны in-addr.arpa и ip6.arpa в реестре AFRINIC, отдельные атрибуты nserver и полное удаление объекта domain только при неисправности всех указанных в нём серверов. Он не затрагивал само распределение адресов, прямой DNS, входящие записи ресурсов меньшинства других RIR или legacy-ресурсы.
  • Полная переработка текста не изменила заявленный авторами результат, но изменила видимость процедуры. Периодичность и повторяемость тестов, адресаты и число уведомлений, срок исправления, доказательственный след, порядок оспаривания и скорость восстановления оказались не в норме, а в не обязательной для политики сфере реализации сотрудниками.
  • Описания 2018 и 2021 годов показывают, что технические гарантии можно было выразить точно: месячный либо ежедневный цикл, несколько проверок, несколько адресатов, географически разнесённые точки, объявленные дни уведомления и удаления. Но это разные последующие эксплуатационные этапы, а не условия, уже записанные в Draft 2.
  • AFRINIC вправе как частный технический координатор поддерживать правдивость родительской записи обратного DNS. Из этого не возникает суверенная, регуляторная, полицейская, карательная, конфискационная или судебная власть. Любое действие должно быть привязано к конкретному дефекту зоны и отделено от членского статуса, платежей, передачи ресурсов, коммерческих отношений и иных споров.

L3 — Что сохранил Draft 2 и что он передал сотрудникам

История переписывания начинается не с абстрактного спора о полномочиях, а с различия между двумя технически плохими исходами. Если делегации нет, резолвер относительно быстро получает отсутствие данных. Если родительская запись направляет его к серверу, который недоступен, не отвечает или не является авторитетным для зоны, данных тоже не будет, но перед этим появляются лишние запросы, ожидание тайм-аутов и перебор альтернатив. Lame-делегация поэтому не просто некрасивая строка в базе. Она заставляет инфраструктуру обещать путь к ответу, которого в действительности нет. Исправить такое расхождение — законная и полезная задача регистратора.

Draft 1, поданный 11 апреля 2017 года D. Shaw, A. Phokeer, N. Goburdhan и J. Engelbrecht, описывал эту задачу как последовательность наблюдаемых операций. Предлагались периодические автоматические проверки каждого объекта domain и каждого атрибута nserver, включая проверку ответа и корректного SOA. Первое неудачное наблюдение не должно было автоматически становиться основанием для изменения записи: результат сначала фиксировался, затем требовались повторные неудачные проверки и лишь после них сервер помечался как lame. Уже здесь виден важный принцип — между единичным сетевым сбоем и устойчивой неисправностью должна существовать доказуемая дистанция.

Уведомление в Draft 1 также понималось не как единственное письмо по единственному адресу. Текст предусматривал параллельное обращение к admin-c, tech-c и zone-c, допускал контакты org и mnt-by, требовал больше одной попытки и предлагал публично стандартизировать частоту, способ и число сообщений. Такая конструкция учитывала обычную реальность инфраструктуры: запись контакта может устареть, один ответственный может быть недоступен, а техническая команда и административный владелец могут узнавать о проблеме по разным каналам. Разумность контакта здесь измеряется не намерением отправителя, а вероятностью того, что оператор действительно получит сигнал и успеет устранить дефект.

Мера была пообъектной и позонной. Один и тот же nameserver может корректно обслуживать одну зону и быть неавторитетным для другой, поэтому Draft 1 не позволял превращать неисправность в одной делегации в глобальный вывод о сервере. Удаляться должен был только тот указатель, чья lame-характеристика установлена именно для данного объекта. Если часть серверов работала, сохранялись рабочие пути. Только если удалению подлежали все nserver, исчезал весь объект domain. Предусматривались автоматизированное изменение, возможная пометка, доступный участнику архив и путь восстановления после исправления серверов. Это не доказывало безошибочность каждого будущего теста, но делало логику решения видимой.

Сфера действия также была очерчена. Речь шла об обратном DNS под in-addr.arpa и ip6.arpa, управляемом AFRINIC через объекты domain в его реестре. Входящие записи ресурсов меньшинства, относящиеся к другим региональным регистраторам, и legacy-делегации исключались. Это не была политика прямого DNS и не был механизм аннулирования адресного пространства. Удаление nserver из объекта обратной зоны меняло конкретную родительскую делегацию, но не стирало IP-адреса оператора, не лишало его маршрутизации и не давало AFRINIC общего права распоряжаться всеми применениями адресного ресурса.

В мае сотрудники AFRINIC сообщили, что в проанализированной части обратного пространства доля lame-записей составляла приблизительно 44 процента. Эта оценка принадлежит учреждению и описывает проведённый им анализ; она не является независимой проверкой каждого случая. Тем не менее масштаб поддерживает сильную благожелательную версию предложения. При большом числе сломанных ссылок индивидуальная ручная работа будет непоследовательной, а автоматизированная, ограниченная процедура может снизить пустую нагрузку и сделать реестр точнее.

Сотрудники оценивали разработку и тестирование примерно в два месяца и перечисляли проверки, уведомления, отчёты, публичный инструмент проверки, архивирование, удаление, восстановление и документацию как необходимые элементы реализации.

Одновременно оценка сотрудников показывала стремление сохранить операционную свободу. Они просили явным образом исключить записи других RIR и legacy-ресурсы, хотели иметь усмотрение в выборе адресатов и процессе уведомления, ставили под вопрос явную норму о восстановлении. Само по себе это не свидетельствует о недобросовестности. Люди, эксплуатирующие систему, действительно видят, какие контактные поля пригодны, какие тесты дают шум и как меняется сеть.

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

Draft 2 был опубликован 22 ноября 2017 года как версия 2.0. История редакции прямо называла его полной переработкой ради простоты и ясности. Авторы заявили, что намерение, действия и результаты не изменились. Одновременно они сообщили об удалении фона, терминологии, объяснений, описания влияния, мотивировки и возможных деталей реализации. Это сочетание утверждений нужно читать буквально, без приписывания скрытого мотива. Цель — очистить lame-указатель, действия — определить неисправность, попытаться связаться и удалить запись, результат — более правдивый родительский объект — действительно могли оставаться прежними.

Однако распределение ответственности за установление порога стало иным.

Короткий нормативный остаток Draft 2 говорил: когда атрибут nserver признан lame для домена и предприняты разумные попытки связаться с ответственными лицами, этот атрибут должен быть удалён из данного объекта, а действие следует отразить строкой remarks. Если lame признаны все записи nameserver, объект domain удаляется целиком. История должна храниться разумное время и предоставляться по необходимости. Каждое из ключевых слов задаёт направление, но не измерение. Что значит «признан», сколько попыток составляют «разумные», кому именно писать, как долго хранить историю и кому она доступна — обязательный текст не уточнял.

Тем самым Draft 2 сохранил пропорциональность результата, но ослабил наблюдаемость пути к нему. Его узость нельзя недооценивать. Удаляется не здоровый сервер из другой зоны и не nameserver повсюду, где встречается его имя. При частичной неисправности удаляется один атрибут в одном объекте, а рабочие серверы остаются. Полное удаление объекта происходит только тогда, когда все указанные серверы для него признаны lame. Именно эта ограниченность отличает санитарную коррекцию от широкого административного воздействия. Она должна быть исходной точкой анализа, а не уступкой в конце критического текста.

Но узкий объект действия не делает безразличной процедуру. Ошибка в определении того, что все серверы lame, превращает позонную меру в исчезновение всей обратной делегации. Удаление обратной записи не равно удалению IP-распределения или прямой зоны, однако способно затронуть почтовую репутацию, диагностику, обработку злоупотреблений, обслуживание клиентов и передачу операционных обязанностей. Экономический эффект возникает не потому, что AFRINIC получил власть над бизнесом, а потому, что реестровая зависимость встроена в работающую инфраструктуру.

Частный технический шаг может иметь реальные последствия, оставаясь при этом частным техническим шагом.

Draft 2 сослался на пример эксплуатационного руководства, однако специально оговорил, что руководство не является частью политики и может не соответствовать окончательной реализации сотрудниками. Эта оговорка решает главный вопрос текста. Нельзя считать, что любое число тестов, срок ожидания или схема уведомлений из примера стало обязательством 22 ноября 2017 года. Ссылка могла помочь участникам представить работу системы, но не превращала пример в норму. Если сотрудники позднее меняли периодичность, точки наблюдения или календарь писем, они не обязательно меняли Draft 2: документ заранее оставил эти переменные за своим пределом.

На встрече AFRINIC-27 30 ноября авторы вновь описали Draft 2 как полную переработку ради простоты и ясности и заявили о неизменности намерения, проблемы и обоснования. В протоколе им приписана позиция, что сотрудникам не хватало основания изменять или удалять данные участников в WHOIS без явно принятой политики, тогда как детали реализации должны были оставаться у сотрудников. Это аккуратная формулировка внутренней организационной потребности. Она объясняет, почему требовался утверждённый текст, но не создаёт публично-правовой власти.

Частная организация устанавливает правила обслуживания собственной координационной системы; её совещание не становится законодательным органом, а её участники не образуют суверенный народ.

После презентации предложение направили на Last Call. Он шёл пятнадцать календарных дней, с 1 по 16 декабря 2017 года. В переписке была выражена поддержка, а позднее один участник возразил, что отчёт сопредседателя недостаточно отразил обсуждение и обратную связь Last Call; другой участник защищал процесс. Закрытая совокупность материалов доказывает существование разногласия, но не позволяет признать возражение обоснованным или, наоборот, окончательно его опровергнуть. Для предмета Draft 2 важно другое: объявление консенсуса и последующая корпоративная процедура не восполнили отсутствующие в тексте измеримые гарантии.

Совет ратифицировал Draft 2 21 марта 2018 года. В протоколе обсуждался возможный конфликт из-за того, что двое авторов были сотрудниками; совет решил, что само это обстоятельство не создавало конфликта для директоров, а генеральный директор воздержался от голосования из-за сочетания ролей сотрудника и директора. Это часть хронологии, а не доказательство скрытой заинтересованности и не самостоятельный сюжет. 22 августа 2018 года раздел 10.7 вошёл в руководство политики. И ратификация, и включение оставались актами частной организации.

Они не превращали техническую запись в источник права собственности и не наделяли AFRINIC функциями регулятора или суда.

Поэтому формула «намерение, действия и результат не изменились» совместима с существенным управленческим сдвигом. Она описывает то, к чему стремится процедура, но не то, кто определяет достаточность доказательств на границе между наблюдением и изменением записи. Draft 1 помещал больше этой границы в видимый текст. Draft 2 оставил обязательный результат и общие условия, но передал настройку порога сотрудникам. Это не означает, что сама очистка стала неправомерной. Это означает, что оценивать Draft 2 нужно не только по конечной команде, но и по тому, насколько частный координатор сделал собственное усмотрение воспроизводимым и проверяемым.