Диагностика медленного DNS-разрешения

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

Обычные подозреваемые

• Неправильно настроенный или перегруженный резолвер: у резолвера вашего интернет-провайдера плохой день случается чаще, чем принято считать, а переход на публичную альтернативу вроде 1.1.1.1 или 8.8.8.8 — полноценный диагностический шаг, а не просто обходной путь.
• Длинная цепочка CNAME: каждый переход, который резолвер должен пройти, прежде чем добраться до настоящей записи A/AAAA, добавляет задержку, а цепочка из четырёх-пяти переходов складывается в заметное время.
• Очень короткий TTL, из-за которого вместо быстрых кешированных ответов выполняются частые полные запросы: он полезен для быстрого распространения, но дорого обходится средней скорости, если задан гораздо короче, чем действительно нужно.
• Проблемы сетевого пути между вашим резолвером и авторитативными серверами, не имеющие ничего общего с DNS-программным обеспечением: потеря пакетов, проблемы маршрутизации или географическое расстояние до сервера имён, у которого нет ближайшего anycast-узла.

Отделяем DNS от всего остального

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

Это стоит проверить, а не предполагать: множество жалоб на «медленный сайт» вообще не связаны с сервером или кодом сайта, а множество других, которые выглядят как общее замедление, на самом деле связаны именно с DNS и устраняются изменением TTL или резолвера.

Почему anycast-резолверы обычно быстрее

Публичные резолверы вроде 1.1.1.1 и 8.8.8.8 обычно работают быстрее резолвера провайдера по умолчанию не из-за более умного программного обеспечения, а благодаря anycast: один и тот же IP-адрес анонсируется из десятков физических точек по всему миру, и сетевая маршрутизация автоматически отправляет ваш запрос в ту, что топологически ближе. Собственный резолвер провайдера, напротив, часто находится в одном (или нескольких) центрах обработки данных, а это может означать заметно более долгий путь туда и обратно в зависимости от того, где вы находитесь относительно него. Поэтому смена резолвера — законный первый шаг диагностики, а не суеверие: она затрагивает реальную физическую разницу в расстоянии и маршрутизации, а не просто эффект плацебо.

Когда медленно у всех, а не только у вас

Если домен медленно разрешается из нескольких разных сетей и через разные резолверы, а не только через один, проблема, скорее всего, переместилась с «вашего пути до резолвера» на «собственную авторитативную инфраструктуру домена». Так могут проявляться единственный не-anycast авторитативный сервер имён, находящийся на большом сетевом расстоянии от значительной части реальных посетителей, авторитативный сервер под высокой нагрузкой или большая зона DNS, которая медленно передаётся. Здесь массовое сравнение через несколько резолверов информативнее одиночного запроса: стабильная медлительность во всех точках наблюдения указывает на проблему выше по цепочке, у собственного DNS-провайдера домена, а не в какой-либо одной промежуточной сети.