Кратко

  • В предложении 2026.4 Ричард Лаагер рассказал о детальной передаче части своего NET другой организации. Ключ родительской сети не проходил GET дочернего NET по хендлу, хотя мог удалить запись и получить её через mostSpecificNet; ключ получателя выполнял GET по хендлу.
  • 30 марта 2026 года ARIN ответила, что другие существующие способы получения данных и будущие планы делают изменение текущих разрешений API ненужным. Предложение закрыли с согласия автора.

Запись можно убрать из реестра, но прочитать её по указанному в реестре имени нельзя. Такой порядок операций описал Ричард Лаагер в предложении ARIN 2026.4. Сначала он сделал детальную передачу из своей родительской сети NET в другую организацию. Затем попробовал получить дочерний NET по хендлу с ключом API родительской стороны. В ответ пришёл отказ из-за прав. При этом, по его словам, та же сторона могла удалить дочернюю запись, найти её по началу и концу диапазона через mostSpecificNet, а общедоступный Whois показывал ту же информацию без входа.

Детальная передача оставляет у записи две заинтересованные организации. Руководство ARIN по ресурсам говорит, что получатель с собственным Org ID может управлять переданными адресами. Непосредственный регистрант сохраняет возможность отозвать передачу. Управление объектами IRR и обратным DNS, связанными с этой записью, разделено между сторонами. Поэтому спор нельзя свести к вопросу, «кому принадлежит NET». Важно, какое отношение учитывает конкретный вызов API.

Лаагер перечислил четыре наблюдения. Ключ получателя читал дочерний NET по хендлу. Родительский ключ на этом адресе API получал отказ. Родительский ключ находил объект по диапазону адресов, а любой пользователь Whois мог видеть публичные данные по хендлу или IP. Секретность самой записи не объясняет такой результат. Различие возникает на пересечении учётной записи и маршрута запроса.

Документация Reg-RWS описывает эти маршруты отдельно. GET /rest/net/NETHANDLE возвращает данные NET. GET /rest/net/mostSpecificNet/STARTIP/ENDIP выбирает наиболее конкретную запись для диапазона. DELETE /rest/net/NETHANDLE создаёт обрабатываемый по тикету запрос на удаление передачи или перераспределения; прямую выдачу адресов такой метод не стирает. PUT /rest/net/NETHANDLE изменяет запись с предоставленным содержимым. Автоматический клиент, сохранивший хендл после создания записи, не может считать успешный поиск по диапазону подтверждением разрешения на GET по хендлу.

Цена разницы проявляется в обычной сверке. Система провижининга хранит хендл дочернего NET, чтобы затем проверить фактическое состояние реестра. При отказе GET ей нужно сохранить ещё и границы адресов, сделать другой запрос, проверить хендл, родительскую запись, диапазон и получающую Org у найденного объекта. Только после этого можно сравнивать его с планом. Публичный Whois полезен человеку, но оставляет иной след доказательств. Вариант «удалить и создать заново» разрушителен: сбой чтения не превращает регистрацию клиента в расходный тестовый объект.

Лаагер предложил широко разрешить GET для NET. Он также хотел дать родительской стороне PUT на прямого потомка: если она может удалить и воссоздать его, зачем запрещать изменение? Это отдельное решение об управлении. Руководство по модификации NET упоминает изменение имени сети, контактных хендлов и публичных комментариев. Чтение доступных через Whois данных и запись этих полей требуют разных оснований. Предложение о PUT осталось предложением автора. ARIN его не приняла.

Ответ ARIN датирован 30 марта. Организация рассмотрела иные действующие способы получения информации и будущие планы разработки, после чего сочла изменение текущей проверки разрешений ненужным. Лаагер согласился закрыть обращение. ARIN не сообщала о выпуске исправления для GET по хендлу. Её выбор оставил на стороне клиента обязанность найти рабочий путь и сверить личность возвращённого объекта.

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

У одной записи есть хендл, диапазон и два связанных оператора. ARIN оставила двери API с разными проверками. Родительской организации теперь приходится помнить, какая дверь откроется её ключом, даже когда все дороги ведут к одному NET.

Предложение и ответ ARIN · Методы Reg-RWS · Управление ресурсами · Изменения NET