Кратко

  • Родитель публикует CNAME для каждого адреса и направляет запрос в отдельно обслуживаемую дочернюю зону.
  • Дочь управляет PTR, но не получает право менять родительский путь.
  • Рабочая цепочка DNS не подтверждает распределение, ROA, BGP, прямую зону, почтовую аутентификацию или результат приложения.

Обычная зона 2.0.192.in-addr.arpa соответствует /24. В примере RFC 2317 этот диапазон делится на /25 и два /26, но обычного разреза зоны на 25-м или 26-м бите нет.

Решение создаёт метки 0/25, 128/26, 192/26, делегирует их NS-записями и добавляет в родителе CNAME для каждого адреса. Запрос для 192.0.2.129 переходит к 129.128/26.2.0.192.in-addr.arpa, где дочь хранит PTR. Существующий резолвер просто следует CNAME.

Это совместимость с ценой: почти 256 псевдонимов, ещё один оператор в цепочке и рекомендация обслуживать дочерние зоны вторично на серверах родителя. Повторно применять трюк нельзя — цепочка CNAME становится менее надёжной.

PTR сообщает имя. A-запись сообщает адрес для имени. RFC 6480 отдельно определяет сертификаты ресурсов и ROA для разрешения AS объявлять префикс. SPF, DKIM и DMARC отдельно проверяют почтовые идентификаторы. BGP, пересылка, соединение и приложение дают другие наблюдения.

Поэтому точный PTR может сосуществовать с несуществующим узлом или неработающим сервисом. RFC 2317 делегировал редактирование обратных имён, а не весь стек управления.