Кратко

  • RFC 5158 — информационный документ марта 2008 года о самостоятельном делегировании обратного DNS для 6to4.
  • В 6to4 внешний IPv4-адрес помещался после 2002::/16 и определял /48 сайта.
  • Сервис создавал обычное одноуровневое DNS-делегирование под 2.0.0.2.ip6.arpa.
  • Клиент мог запросить только /48-зону, вычисленную из наблюдаемого исходного адреса 6to4.
  • Первичный и вторичный серверы должны были быть доступны, авторитетны и совпадать по SOA и набору NS.
  • HTTPS защищал запрос, но не доказывал полномочия клиента от имени администратора сайта.
  • В документе адресная аутентификация названа примитивной и допускающей подмену источника.
  • Внутренний узел без локальных ограничений мог изменить делегирование без ведома администратора.
  • После динамической перевыдачи IPv4 новый сайт мог унаследовать обратное состояние прежнего пользователя.
  • Проверка, предупреждение и удаление очищали отказавшую инфраструктуру, но не восстанавливали историю полномочий.
  • RFC предупреждал, что наличие или отсутствие PTR ненадёжно подтверждает связь имени с адресом.
  • Для расследования нужны отдельные квитанции об источнике, сроке выдачи адреса, согласии, состоянии DNS и содержимом PTR.

Удаление было последним шагом автомата состояний

До публикации сервис проверял предложенные серверы. Первичный и хотя бы один вторичный должны были отвечать авторитетно, иметь одинаковый SOA и публиковать идентичный набор NS. Это не позволяло сразу поставить в родительскую зону явно неподготовленного ребёнка.

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

Однако её входом была доступность DNS. Автомат не получал событие о завершении договора на IPv4, решение администратора или данные о личности пользователя. Поэтому его выход «удалено» означал только, что политика живучести исчерпала допуски.

Последняя исправная запись могла принадлежать предшественнику

Адрес 6to4 строился детерминированно: 32 бита внешнего IPv4 входили в префикс после 2002::/16. При повторной выдаче того же IPv4 другой клиент получал тот же /48 и то же имя обратной зоны. Синтаксис сохранял непрерывность там, где субъект сменился.

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

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

Низкий TTL ограничивал память резолвера

Короткие TTL уменьшали срок хранения положительных ответов и помогали изменениям быстрее распространяться. Они не отзывали родительское делегирование и не завершали полномочия сервера. После истечения TTL резолвер снова спрашивал цепочку; если старое состояние оставалось доступным, оно возвращалось заново.

Таким образом, срок кэша, тридцатидневный интервал проверки, четырнадцатидневный льготный период и реальный срок аренды IPv4 были разными часами. Самый короткий из них не становился универсальным сроком доверия.

Право контролирующей IPv4 стороны отдельно потребовать блокировку регистрации показывало ещё одну линию власти. Возможность клиента подать заявку и возможность владельца ресурса остановить процесс принадлежали разным ролям и могли расходиться во времени.

Защищённый запрос не восстанавливал полномочия

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

Но RFC прямо считал адресную аутентификацию грубой. Источник можно подделать в некоторых условиях, а внутреннему узлу даже не требовалась подделка: он уже находился в правильном /48. Без локального ACL или межсетевого экрана такой узел мог изменить делегирование, не имея поручения администратора.

После удаления делегирования следы этого различия особенно легко потерять. Журнал сервиса может хранить успешный HTTPS-сеанс и последующий сбой серверов, но не знать, был ли исходный заявитель уполномочен. Завершённый жизненный цикл не равен подтверждённой истории субъектов.

PTR оставался утверждением внутри DNS

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

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

Поэтому минимальная доказательная запись должна сохранять исходный адрес, ответ, цепочку авторитета, TTL, время запроса, интервал выдачи IPv4 и основание локального одобрения. Имя можно использовать как подсказку, но не как самостоятельное удостоверение.

Исторический статус не отменяет урока об удалении

Последующие рекомендации описали эксплуатационные проблемы 6to4, а механизм anycast relay был объявлен устаревшим. Современные требования TLS обновили старую зависимость RFC. Упомянутое в спецификации историческое имя сервиса не доказывает его нынешнюю доступность.

Тем не менее многие современные системы удаляют состояние после нескольких неудачных health check. RFC 5158 показывает границу такой политики. Удаление способно остановить дальнейшее распространение состояния; оно не объясняет, кто создал это состояние, кто имел право и какие решения уже приняли потребители.

Источники

  1. RFC 5158, HTML
  2. RFC 5158, текст
  3. Карточка RFC Editor
  4. Карточка IETF Datatracker
  5. История RFC 5158
  6. Ссылки RFC 5158
  7. Исправления RFC 5158
  8. RFC 3056
  9. RFC 3068
  10. RFC 3964
  11. RFC 6343
  12. RFC 7526
  13. RFC 2136
  14. RFC 3596
  15. RFC 2317
  16. RFC 1034
  17. RFC 1035
  18. RFC 4033
  19. RFC 8996
  20. RFC 8446
  21. Реестр IANA специальных IPv6-адресов
  22. RFC 3172
  23. RFC 8020
  24. RFC 2308
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy