Кратко

  • В описании обновления от 19 августа AFRINIC переносит результат проверки IPv6 у серверов ccTLD на все сайты ниже по иерархии. Но транспорт DNS-запроса не определяет семейство адресов в ответе.
  • Рекурсивный резолвер с поддержкой обоих протоколов даёт контрпример. Итерация только по IPv6 без рабочего альтернативного пути к необходимому серверу действительно может столкнуться с ограничением. Измерений DNS и сбоев приложений здесь не проводилось.

Телефон и его резолвер могут пользоваться разными дорогами. Телефон отправляет вопрос по IPv6. Резолвер обращается к родительской зоне по IPv4, получает направление к дочерней зоне и по доступному пути запрашивает у её авторитетного сервера запись AAAA. Ответ возвращается телефону по IPv6. Последующее соединение с отдельно доступным сайтом тоже может идти по IPv6.

Это условный пример архитектуры, а не опыт на африканской сети. Он показывает, почему полезная проверка AFRINIC не даёт права на столь широкий вывод.

Монитор развёртывания IPv6 и DNSSEC добавил вкладку для самих национальных доменов верхнего уровня. В описании версии 2.14.0, датированном 19 августа 2026 года, разделены три вопроса к серверам реестра: есть ли адрес IPv6, отвечает ли сервер по этому транспорту и способен ли он действительно отвечать на DNS-запросы? Различать эти наблюдения важно.

Затем объяснение утверждает, что недоступность серверов реестра по IPv6 означает недоступность по IPv6 всего, что находится ниже, независимо от настройки отдельных доменов. Даже для имени, действительно делегированного под этим ccTLD, такой вывод не обязателен. Иерархия DNS определяет порядок поиска нужных серверов. Она не требует одной версии IP для каждого обмена, запроса пользователя и конечного соединения с приложением.

Адрес в записи не наследует транспорт запроса

RFC 3596, опубликованная в октябре 2003 года, прямо разделяет транспорт DNS и семейство адресов, описываемых записями. По IPv4 можно запросить адресные данные IPv6; по IPv6 — данные об адресах IPv4.

При этом сервер ccTLD не обязан возвращать окончательную AAAA-запись сайта. Он может сообщить делегирование дочерней зоны. Резолвер проходит дальше, обращается к её авторитетному сервису через доступный транспорт и получает нужные данные уже там. У каждого этапа свои требования к связности.

Контрпример предполагает, что все необходимые авторитетные этапы доступны, данные корректны, а у приложения есть собственный работающий путь IPv6. При этих условиях обращение к ccTLD по IPv4 само по себе не мешает конечному соединению клиента по IPv6. Ранее сохранённый в кэше ответ тоже не требуется. Эти условия показывают предел общего утверждения, а не доказывают исправность конкретной страны или сети.

RFC 4472, информационный документ апреля 2006 года, вновь объясняет независимость транспорта от запрашиваемых записей. Машина, которая обращается к авторитетному серверу, часто не совпадает с машиной, использующей полученный адрес. У промежуточного резолвера есть собственные интерфейсы и маршруты.

Обратное упрощение столь же неверно. Получение AAAA не доказывает, что приложение работает по IPv6. Маршрутизация, фильтрация, готовность сервиса принимать соединения и путь до него остаются отдельными вопросами. Правильный DNS-ответ родительской зоны не проверяет их автоматически.

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

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

RFC 3901, рекомендации по транспорту DNS IPv6 сентября 2004 года, различает прямой поиск и пересылку запросов рекурсивному сервису с обоими протоколами. Её исторические советы нельзя выдавать за новый запрет клиентов только с IPv6 в 2026 году. Обслуживать пользователя по IPv6 и использовать только IPv6 при обращениях к авторитетным серверам — разные решения.

Сам монитор вводит полезные оговорки. Проверки идут из одной точки в Африке; настоящий DNS-ответ важнее ответа на пинг. Версия 2.15.0 добавляет вопросы о больших подписанных ответах и согласованности делегирования. Это усиливает инструмент, но не превращает одну точку наблюдения во всемирный тест приложений.

В сентябре мы разбираем объяснение функции, опубликованное в августе, а не новый сентябрьский выпуск. Старые числа из истории версий не являются текущими измерениями этого материала. DNS-запросы и проверки приложений не выполнялись; общенациональный сбой или сегодняшняя неисправность серверов не установлены. Проверку ccTLD стоит сохранить, сузив объяснение до зависимости, которую она действительно исследует.