Кратко

  • Данные делегации публикуют и родительская, и дочерняя зоны; TTL у этих копий может различаться. Уменьшение TTL у дочерней зоны не сокращает срок уже закешированной родительской копии.
  • RFC 9199 описывает измерение, где около 90% резолверов выглядели ориентированными на дочернюю копию, а примерно 10% — на родительскую. Сроки адресов серверов также зависят от положения относительно bailiwick.
  • Старую инфраструктуру следует держать в рабочем состоянии как минимум до истечения большего из двух TTL. Для решения об отключении нужны время последнего старого заполнения, TTL A/AAAA и последняя фиксация старого пути для разных классов резолверов.

Миграция заканчивается не в момент публикации

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

Родительская зона сообщает NS, ведущие к дочерней. Сама дочерняя зона затем отдаёт собственный набор NS. Имена должны совпадать, но срок кеширования может быть разным. Оператор дочерней зоны контролирует свой TTL и часто не может изменить фактический TTL у родителя.

RFC 9199 приводит характерный пример: NS для доменов верхнего уровня в корневой зоне имеют TTL двое суток, хотя сам TLD может публиковать у себя гораздо меньшее значение. Для резолвера обе копии получены легитимно, а выбор срока зависит от реализации.

Giovane Moura, Wes Hardaker, John Heidemann и Marco Davids измерили это поведение в реальной среде. В изложении RFC 9199 примерно 90% наблюдавшихся резолверов казались ориентированными на дочерний TTL, а около 10% — на родительский. Это не вечная доля для всего Интернета. Но даже такая выборка запрещает считать меньшинство несущественным.

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

Короткий TTL не умеет отзывать старую запись

TTL — не удалённая команда таймера. Резолвер получает длительность вместе с данными и отсчитывает её локально. В DNS нет механизма, которым авторитетный оператор мог бы отозвать все сохранённые копии или уменьшить их остаток. Новое значение действует на будущие заполнения.

Снижение TTL перед плановой работой эффективно только при правильной хронологии. Малое значение сначала должно реально стать авторитетным на каждой нужной поверхности. Затем истекает последняя запись, которая могла попасть в кеш со старым большим значением. Лишь после этого безопасно переходить к отключению. Один час у дочерней зоны не отменяет 48 часов у родителя.

Поэтому RFC 9199 требует оставлять старую инфраструктуру работоспособной как минимум до максимума родительского и дочернего TTL. Максимум — нижняя граница планирования, а не автоматическое доказательство очистки. Нужно учитывать время обновления родителя, последнее возможное старое заполнение и самостоятельные сроки адресов серверов.

Длинный TTL снижает задержку при попадании в кеш, нагрузку и стоимость, а также помогает пережить короткую аварию. Короткий облегчает перенос, балансировку и перенаправление. У каждого выбора есть основания. Ошибка возникает, когда решение дочерней зоны принимают за решение всех остальных участников.

У имени и адреса разные часы

NS указывает имя сервера, но для запроса нужен адрес A или AAAA. Способ получения адреса добавляет ещё одну границу кеша.

Если nameserver находится внутри bailiwick дочерней зоны, родитель может передать glue, чтобы избежать циклического разрешения. По данным, пересказанным в RFC 9199, большинство измеренных резолверов повторно запрашивало in-bailiwick-адрес при истечении NS и новой потребности в glue, даже если исходный TTL адреса был длиннее.

Адрес out-of-bailiwick-сервера обычно разрешается отдельным путём и кешируется независимо. Истечение NS не обязательно завершает остаток старой A/AAAA. Значит, увидеть новый NS и действительно отправить запрос на новый адрес — разные события.

В журнале миграции нужны старые и новые NS RRset у родителя и дочерней зоны, все адреса, TTL NS/A/AAAA, классификация bailiwick, момент фактической публикации малых значений и последний возможный вход каждого старого значения в кеш. Одна строка «TTL 3600» удаляет критически важное разветвление.

RFC 2181 различает достоверность DNS-данных по источнику. Но это не право дочерней зоны глобально перезаписать кеши. Родитель авторитетен для своей зоны и делегации, дочерняя зона — для собственных данных. Резолвер хранит источник, контекст и оставшийся срок по реализованным правилам.

Нужна квитанция последнего старого пути

Доказательство начинается до переключения. Фиксируются обе версии RRset, адреса, TTL и время публикации. Для каждого старого значения вычисляется последний момент возможного заполнения. Оба endpoint должны полноценно отвечать всё окно; включённая, но деградировавшая машина не сохраняет путь.

Проверки проводят через разные семейства резолверов и сети. Для каждой точки сохраняют реализацию или провайдера, версию при наличии, время, источник ответа, остаточный TTL и достигнутый авторитетный endpoint. Первый новый ответ доказывает существование нового пути. Последний старый ответ по классу отмечает фактический хвост.

Нулевой трафик на старом сервере — полезный, но не всеобщий факт. В наблюдаемой выборке могло не быть подходящего запроса. Один публичный резолвер не представляет все политики. Недоступное состояние родителя, неизвестное кеширование и serve-stale остаются явными неопределённостями.

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

Соавторство не означает единоличный контроль

Авторы RFC 9199 — Moura, Hardaker, Heidemann и Davids. Это Informational RFC в Independent Stream, а не консенсус IETF и не Internet Standard. Сохранённый профиль IETF связывает вклад Wes Hardaker с исследованиями DNS, многолетней работой в IETF и помощью в эксплуатации B-root. Контекст не превращает совместную работу в личное изобретение.

Принцип agency у Heng Lu распределяет полномочия: оператор родителя решает за делегацию, дочерняя зона — за свою копию, разработчики и операторы рекурсивных сервисов — за кеш и bailiwick, инфраструктурная команда — за снятие старого endpoint. Никто не обещает состояние остальных.

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

Общий ledger координирует участников, но не получает власть над ними. Он сводит часы родителя, дочерней зоны, адресов и действие отключения в одну проверяемую запись. Старый сервер остаётся не из боязни перемен, а потому что некоторые действующие кеши всё ещё имеют право его найти.

Источники