Кратко

  • В 116 050 253 тестах без ответа APNIC Labs увидела на авторитетном сервере 9 685 775 212 запросов. Из опубликованных сумм получаются 83,46 запроса на уникальный тест против 3,43 для положительного контроля, 3,93 для NODATA, 4,40 для NXDOMAIN, 11,47 для REFUSED и 51,73 для SERVFAIL.
  • Эти отношения доказывают связь состояния ответа с нагрузкой в данном эксперименте. Они не показывают, откуда пришли повторы: с конечного устройства, из stub-резолвера, форвардера, рекурсивного движка, фермы резолверов или сразу из нескольких уровней.
  • Для двух средних значений текст источника расходится со сводной таблицей. Пересчёт по опубликованным счётчикам подтверждает значения таблицы, но не авторский замысел. Поэтому для эксплуатационного решения нужен паспорт измерения с исходным знаменателем, формулой, топологией, транспортом, состоянием безопасности и явной неизвестностью атрибуции.

Счётчик бывает точным, даже когда субъект неизвестен

Самое большое число в отчёте APNIC Labs от 4 сентября — 9 685 775 212. Столько запросов увидел авторитетный сервер, когда эксперимент не возвращал никакого ответа. В знаменателе сводной таблицы стоят 116 050 253 теста. Деление даёт 83,4619 запроса на уникальный тест.

Арифметика проста. Путь, который её создал, — нет.

Сценарий в интернет-рекламе заставлял конечное устройство разрешать случайно составленное имя. Локальная библиотека могла обратиться к одной из нескольких настроенных рекурсивных служб. Между ними мог находиться форвардер. Крупная служба могла распределить запрос по фронтендам и движкам. Движок мог попробовать другой адрес или транспорт. Каждый компонент способен создать работу, объединить равнозначные обращения, повторить отправку или передать вопрос дальше.

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

Фраза «один резолвер послал 83 запроса» добавила бы факт, которого нет в опыте. Даже «83 повторные попытки» — слишком грубое название. Современное устройство вправе спросить у одного имени данные A, AAAA и HTTPS. Это разные типы, а не три повтора одного пакета. APNIC вычитает ожидаемую основу, прежде чем обсуждать повторение, но опубликованной единицей всё равно остаётся уникальное тестовое имя, а не одно действие человека, один запрос приложения, одна stub-транзакция или одна рекурсивная транзакция.

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

Шесть состояний ответа дали шесть разных нагрузок

В эксперименте 2026 года применялись случайные имена, чтобы прежний кэш не мог ответить за точное имя. Зона не была подписана. Единственный двухстековый авторитетный сервер принимал UDP и TCP, но не DoT и DoH. Коротким ответам не требовалось усечение. Учитывались запросы, поступившие в течение 24 часов после каждого показа рекламы.

Опубликованные итоги дают такое сравнение:

Состояние авторитетного ответа Тесты Наблюдаемые запросы Пересчитано на тест К положительному контролю
Положительный контроль A/AAAA 254 894 985 875 316 423 3,43 1,00×
NOERROR/NODATA 115 571 398 454 213 932 3,93 1,14×
NXDOMAIN 115 750 503 509 410 787 4,40 1,28×
REFUSED 115 415 259 1 324 355 211 11,47 3,34×
SERVFAIL 138 643 924 7 171 673 166 51,73 15,06×
Нет ответа 116 050 253 9 685 775 212 83,46 24,30×

Картина содержательнее простого сравнения «да» и «нет». Положительный ответ и две окончательные отрицательные формы держатся около четырёх запросов на тест. REFUSED заметно выше. SERVFAIL и молчание переходят в иной диапазон.

Порядок согласуется со смыслом состояний. NXDOMAIN сообщает, что имени нет. NODATA — что имя существует, но запрошенного типа нет. REFUSED означает отказ сервера выполнять операцию, часто по правилам политики. SERVFAIL говорит о проблеме обработки и оставляет открытым вопрос, не поможет ли другой сервер, адрес, транспорт или более поздняя попытка. Молчание не сообщает ничего; смысл отсутствия ответа приходится определять таймерам.

Согласованность ещё не даёт атрибуции. Таблица не показывает, какая реализация прочла RCODE, какой фронтенд повторил отправку, сколько равнозначных обращений были объединены и вызвал ли сбой переключение между адресами. Нет распределения по продуктам и длинного хвоста, скрытого средним. Результат подтверждает связь состояния ответа с нагрузкой внутри опыта. Он не задаёт универсального правила в 51,73 запроса при SERVFAIL.

Ожидаемая основа уже больше единицы

Для NXDOMAIN APNIC сообщает: 48% конечных устройств породили и A, и AAAA, 51% — только A, один процент — только AAAA. Запросы HTTPS были замечены у 39% устройств. Для такого состава APNIC оценила базу в 218 млн запросов, если каждый использованный тип спрашивался ровно один раз.

На деле наблюдались 509 410 787. Оставшиеся 291 919 927 были отнесены к повторам. Из 115 750 503 тестов 67 316 541 завершились не более чем одним запросом каждого использованного типа. В других 48 433 962 тестах сосредоточились все повторы — по 6,03 повторного запроса на тест, в котором они были.

Работа со знаменателем принципиальна. Если сопоставить 509 млн пакетов со 116 млн тестов и всю разницу назвать «ретраями», нормальные параллельные типы будут ошибочно записаны в повторы. Если считать лишь наличие хоть какого-то ответа, из картины исчезнут почти 292 млн дополнительных запросов. Полезная запись должна хранить и ожидаемый набор типов, и превышение над ним.

Нужен и предел охвата. Устройства приходили через Google Ads из обслуживаемых этой системой регионов; крупным исключением отчёт называет Россию. Это широкая видимость, но не вероятностная выборка всех пользователей и резолверов Интернета. Один двухстековый авторитетный сервер — контролируемый прибор, а не обычный многопровайдерный парк. Неподписанная зона и короткие ответы убрали из опыта DNSSEC-проверку и усечение, но не доказали, что эти факторы не важны в других условиях.

Арифметике статьи тоже нужен паспорт

Источник даёт достаточно исходных счётчиков для проверки средних. Проверка обнаруживает два расхождения.

В разделе SERVFAIL текст называет 51,29 средним числом запросов на тест, а 51,59 — средним числом повторов. Итоговые числа этого не дают. Деление 7 171 673 166 запросов на 138 643 924 теста даёт 51,7273, то есть 51,73 в сводной таблице. После вычитания 3 702 576 тестов с «единственным запросом» остаётся 134 941 348 тестов с повторами; 6 920 490 780 повторов, поделённые на этот знаменатель, дают 51,2852 — табличные 51,29.

В абзаце об отсутствии ответа число тестов напечатано как 11,6050,253, а среднее указано как 82,6. В таблице 1 стоят 116 050 253 теста и 83,46. Деление 9 685 775 212 на табличный знаменатель даёт 83,4619. Аналогично воспроизводится среднее повторов 83,38: 9 466 474 491 повтор делится на 113 531 062 теста с повторами.

Правильная реакция — не переписать абзац без проверки и не объявить из-за расхождения весь опыт неверным. Исходные суммы, таблица и формулы должны сохраняться вместе. Тогда читатель отличит опечатку или неверную подпись от ошибки измерения. Только автор источника может сказать, какое текстовое значение имелось в виду; арифметика показывает, какие величины следуют из опубликованных данных.

Это уменьшенная модель главной проблемы. Аккуратно оформленное число не удостоверяет себя само. Знаменатель, исключения и вывод формулы — тоже свидетельства.

Старое измерение даёт гипотезы, но не недостающую личность

В 2019 году APNIC подробнее изучала повторный трафик NXDOMAIN. Были видны пики по времени, повторы с одного наблюдаемого адреса резолвера и серии адресов с общим префиксом. В анализе обсуждались Happy Eyeballs, потеря пакетов, агрессивные таймеры, концентрация на форвардерах и фермы резолверов. Объединение по общему /24 или /48 прямо называлось приближением.

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

Новый отчёт честно формулирует пробел: принадлежит ли повторение самой реализации рекурсивного резолвера или более сложным фронтенд- и бэкенд-системам? Неизвестность необходимо сохранять в пересказе. Иначе исследовательский вопрос превращается в приговор реализации.

По той же причине опубликованное расписание DNS-клиента Microsoft полезно, но недостаточно. Оно показывает конкретный сценарий: молчание заставляет Windows-клиент спрашивать снова и расширять обращение на другие настроенные серверы, тогда как Name Error прекращает эту ветвь. Однако APNIC не установила, что её выборка состояла из Windows-клиентов или следовала этому расписанию. Документ реализации объясняет возможную ветвь, но не заполняет ненаблюдаемое поле другого эксперимента.

Стандарты ограничивают повторы, но не решают атрибуцию

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

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

RFC 2308 придаёт NXDOMAIN и NODATA кэшируемое отрицательное значение и в своей старой модели допускает ограниченное кэширование серверного сбоя. RFC 8914 разрешает Extended DNS Error добавлять диагностику, явно не меняя обработку RCODE. Эти механизмы делают состояния понятнее. Они не разрешают ложноотрицательный ответ ради снижения трафика и не называют субъект повторения, который не измерялся отдельно.

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

Опубликуйте путь, которого не видно в коэффициенте

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

Далее нужен способ формирования ответа на проводе, число серверов, семейства адресов, состояние anycast, поддерживаемые и наблюдаемые транспорты, DNSSEC, размер ответа и усечение. Исходные итоги, суммы повторов, формулы, округление и распределения должны стоять рядом с главным средним.

Важнее всего не вписывать ответ в поле, которого измерение не видело. Если stub-, forwarding- и рекурсивный уровни не инструментированы независимо, их вклад остаётся неизвестным. Там, где позволяют приватность и эксплуатационные границы, контролируемый тест может добавить идентификаторы транзакций на каждой собственной стадии, отметить объединение эквивалентных обращений и отделить повтор на том же сочетании адреса и транспорта от перехода к альтернативе. Где такую цепочку получить нельзя, отчёт должен закончиться на авторитетной границе.

Сложную первую часть APNIC уже сделала: разницу в стоимости теперь нельзя игнорировать. Следующий шаг — не более сильное определение для «шторма», а измерение, способное показать, какой уровень распорядился каким повтором.

Источники