Кратко

  • При двух авторитетных серверах среднее число наблюдаемых запросов снизилось с 3,43 до 2,57 на тест, а доля тестов с одним запросом выросла с 58% до 71%.
  • APNIC Labs не доказала причинный механизм. Диспетчер перед несколькими рекурсивными движками — правдоподобная гипотеза, но не установленная архитектура участников.
  • Надёжная единица учёта должна связывать клиентский запрос, выбор backend, кэш, авторитетную попытку, ответ, решение о повторе и завершение разрешения.
Показатель Один авторитетный сервер Два авторитетных сервера
Тестов 254 894 985 150 221 951
Запросов 875 316 423 385 725 364
Запросов на тест 3,43 2,57
Тестов с одним запросом 58% 71%
Среднее число повторов в тестах с повторами 3,80 2,56

Изменилась сторона назначения, а не класс ответа

В опыте APNIC Labs контрольная зона имела одно имя авторитетного сервера с IPv4- и IPv6-адресом. Затем добавились второе имя и ещё по одному адресу каждого семейства. Ответы оставались положительными. Это не был тест отказа, SERVFAIL или молчания.

При одном сервере почти 255 миллионов тестов дали свыше 875 миллионов запросов на авторитетной стороне. При двух около 150 миллионов тестов дали 386 миллионов запросов. Среди тестов, где повтор всё же возник, его среднее число уменьшилось с 3,80 до 2,56.

Из этих рядов нельзя вывести универсальный совет «два быстрее одного». Объёмы выборок различаются, а авторитетный наблюдатель видит лишь дошедшие пакеты. Твёрдый вывод уже: расширение набора авторитетных целей сопровождалось заметным изменением распределения запросов.

Самая трудная часть лежит раньше обычного тайм-аута

В варианте с одним сервером около 85% дубликатов пришли в первую секунду; с двумя — примерно 75%. К пяти секундам обе кривые достигли приблизительно 90%. В первом случае были пики около 100, 310 и 800 миллисекунд. Во втором появились также пики около 50, 370 и 750 мс.

Основное различие сосредоточилось между 10 и 70 миллисекундами, особенно между 10 и 40. Такой интервал трудно объяснить одним стандартным истечением времени UDP-запроса. Доля повторов быстрее 10 мс тоже уменьшилась — примерно с 17% до 12%.

Предыдущий материал APNIC о негативных ответах задаёт полезную границу. Положительный ответ там давал 3,43 запроса на тест, SERVFAIL — 51,73, отсутствие ответа — 83,46. Это исследование классов отказа, кэширования и усиления. Новый опыт сохраняет положительный ответ и меняет авторитетную топологию. Механизмы нельзя подменять друг другом.

За одним публичным входом могут работать разные часы

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

Такой дизайн реален. Официальное руководство dnsdist описывает приём DNS-запросов, выбор нижестоящего сервера и возврат ответа. Политика может учитывать незавершённые запросы, хэш или веса; возможны несколько потоков приёма и обработки ответов. Но это доказательство возможности, а не атрибуция. Эксперимент не устанавливает ни dnsdist, ни конкретную схему backend.

Anycast, NAT, балансировщики, пулы процессов и частично согласованные кэши создают ту же проблему. IP хорошо указывает, куда отправить пакет. Он не обязан одновременно быть идентификатором клиента, исполнителя и логического разрешения.

Совпадающий кортеж ещё не означает совпадающую работу

RFC 9520 различает сервер, адрес и транспорт и описывает запрос через QNAME, QTYPE и QCLASS. RFC 1035 задаёт 16-битный ID, которым отправитель сопоставляет ответ с ожидающим запросом. Поля необходимы, но полного происхождения не дают.

Диспетчер может переписать ID. Разные движки могут выбрать одинаковое значение. Попадание в кэш вообще не наблюдается на авторитетной стороне. Её журнал не знает начальный stub-запрос, выбранный backend, состояние кэша, сработавший таймер, причину повтора и момент признания результата достаточным.

Поэтому нужна цепочка квитанций. Клиентская граница фиксирует запрос и срок. Диспетчер — выбранный backend. Рекурсивный движок — кэш и делегирование. Каждая исходящая попытка получает имя и адрес авторитетного сервера, транспорт, кортеж и время. Ответ получает класс и результат проверки. Повтор ссылается на ошибку или таймер, а завершение связывает выданный результат с исходным запросом.

Цепочка может оставаться закрытой и храниться недолго. Без неё общий IP становится воображаемым ключом для связи событий, связь которых никто не наблюдал.

Резервирование не объясняет происхождение копий

RFC 2182 требует нескольких авторитетных серверов и подчёркивает сетевое и географическое разделение, одновременно напоминая об операционной цене лишней сложности. Результат APNIC не заменяет эту логику тезисом «два всегда быстрее».

Выбор сервера, семейство адреса, привязка на диспетчере, общий кэш и параллельные попытки остаются возможными объяснениями. Корректный анализ удерживает вместе два положения: наблюдаемое распределение действительно изменилось, а конкретная причина пока не измерена.

Источники