Кратко

  • ARIN строит обратные делегации по CIDR-компонентам прямого выделения адресов. В официальных примерах /23 получает две отдельно управляемые делегации /24, а /16 — одну на уровне /16.
  • Исключение из совместного управления связано с блоком провайдера, из которого клиент получил адреса. Оно не запрещает делегировать подзону средствами DNS, но требует договорённости с оператором родительской зоны.

Обещание управлять своим диапазоном

Представим компанию, которой провайдер передал /24 из своего /16. Компания хочет использовать собственные серверы имён для обратного DNS этих адресов. Это условный пример, а не описанный в источниках спор. Просьба кажется узкой: дать управление своим диапазоном, не затрагивая соседей. Однако граница клиентского диапазона ещё не говорит, какая делегация существует в ARIN и кто может её менять.

В документации ARIN по обратному DNS есть полезное сопоставление. Прямое выделение /23 приводит к созданию двух делегаций /24. Серверы имён для них можно администрировать раздельно. Для /16 создаётся одна делегация /16, и её серверы управляются на этом уровне. Больше адресов — не обязательно больше независимых объектов редактирования в реестре.

Так получается из-за выбранной единицы построения. Для каждого CIDR-блока, составляющего Direct Allocation, то есть прямое выделение, ARIN создаёт максимально крупные поддерживаемые делегации. В IPv4 поддерживаются границы /8, /16 и /24; минимальный поддерживаемый размер — /24. Сам /23 не совпадает с такой границей, поэтому его покрывают два /24. У /16 совпадение точное, и достаточно одной делегации.

Это не означает, что владелец /16 в целом слабее распоряжается своими ресурсами. Его единственный объект охватывает больше адресного пространства. Отличается детализация управления в реестре. Не следует и подменять исходное прямое выделение любым более крупным агрегатом, содержащим адреса клиента. Документированная логика относится именно к его CIDR-компонентам, а не ко всем последующим клиентским записям.

Для IPv6 ARIN описывает границы по четыре бита. Обсуждаемое здесь исключение /16 относится к IPv4. Из него нельзя выводить общее правило о правах всех клиентов во всех семействах адресов.

Условие находится выше клиента

ARIN допускает совместное управление обратным DNS для подходящих прямых и косвенных держателей ресурсов. Указанная для соответствующей зоны уполномоченная организация может участвовать в управлении применительно к переданным ей адресам. Но рядом стоит явное исключение: совместное управление недоступно для повторного назначения или перераспределения из блока /16 либо более крупного блока интернет-провайдера.

Смысл условия задаёт слово «из». Оно не ограничивается ситуацией, когда клиенту передают целый /16. В нашем условном случае клиентский /24 тоже происходит из /16 провайдера. «Более крупный» означает больше адресов и численно меньшую длину префикса, а не большее число после косой черты.

Именно поэтому аккуратная запись о клиенте не доказывает наличие у него самостоятельной кнопки изменения делегации. В описании управления ресурсными записями операция изменения сети позволяет править название, контакты и публичные комментарии, но не делегацию обратного DNS. Общие положения о совместной работе с ресурсами нужно читать вместе со специальной оговоркой для DNS. Различие объектов управления не требует объявлять документы противоречивыми.

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

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

Родительская зона может передать меньше, чем реестр

Следующий шаг — найти оператора самой DNS-зоны. Отсутствие отдельного права редактирования в ARIN не равно запрету клиенту управлять обратными данными.

В RFC 1034 описана иерархия зон и возможность их операторов делегировать подзоны. Родительская сторона должна разместить необходимые записи NS и, когда требуются, связующие адресные записи; данные по обе стороны границы делегирования должны быть согласованы. Провайдер или обслуживающий его DNS-оператор может таким образом передать подзону клиенту, не отдавая аккаунт ARIN и право менять весь /16.

Для обычного /24 под /16 достаточно обычного делегирования подзоны DNS. Клиент получает возможность обслуживать данные внутри неё. Но соединение с родительской зоной остаётся чьей-то работой: при изменениях в серверах имён этот участок должен уметь обновить ответственный оператор. Самостоятельное редактирование дочерней зоны не устраняет зависимость от родителя во всех будущих изменениях.

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

Если речь идёт о менее чем 256 адресах IPv4, RFC 2317 описывает отдельную конструкцию: дополнительные делегированные имена и ссылки CNAME сохраняют существующий механизм DNS-поиска, позволяя разделить управление более мелкими диапазонами. Зависимость от родительской стороны остаётся. Это не свидетельство того, что ARIN создаёт произвольные делегации /25, и не обязательная схема для каждого /24 внутри /16. Объяснять ею любое делегирование означало бы потерять различие между обычной подзоной и специальным решением для меньшего диапазона.

Таким образом, границы регистрации и эксплуатации выполняют разную работу. Реестр поддерживает определённую делегацию; её оператор может организовать более мелкое разделение ниже. Такая конструкция вполне возможна без расширения прав клиента в ARIN. Но она требует реальной передачи обязанностей, которую нельзя считать состоявшейся лишь потому, что адреса уже записаны за клиентом.

Меняется то, что выбрано

Разница видна и в методах Reg-RWS. Объекты делегаций появляются и исчезают вместе со связанными сетями, а не создаются и удаляются независимо. Они определяются именем делегации, не идентификатором NET. Документация предусматривает получение делегаций, связанных с NET, и чтение текущего состояния перед изменением. Это описание интерфейса, а не подтверждение прав конкретного аккаунта: запросов на изменение в ARIN эта работа не выполняла.

Руководство по DNS в ARIN Online показывает реальные обратные зоны, серверы имён, теги ключей DS и организации с совместными полномочиями. Замена серверов имён распространяется на все выбранные делегации и заменяет прежние значения. Название заявки «для клиентского /24» не сужает фактически более широкую выборку.

Если поле TTL оставить пустым, руководство указывает значение 86 400 секунд. Изменение базы происходит сразу, тогда как появление результата в DNS может занять до 24 часов. Это опубликованное описание работы, не измеренный простой и не гарантия одновременного истечения всех кешей. Для вопроса о полномочиях важно другое: сохранить изменение, определить его охват и проверить нужный результат — разные действия.

Источники, доступные 3 сентября 2026 года, позволяют проследить такую модель управления. Здесь не измерялись DNS-ответы клиентов, миграции, отказы, расходы или аварии. Корректная PTR-запись сама по себе не подтверждает маршрутизацию, право собственности или полную идентичность пользователя адреса. Практический вывод скромнее: до выдачи доступа нужно установить, какая зона должна измениться и кто способен изменить её связь со следующим уровнем.