Три причины, почему один домен отвечает по-разному
Геомаршрутизация
Свой edge-сервер в каждом регионе
Кэширование
Независимые TTL и кэши
Split-horizon
Другой ответ — так задумано
Почему DNS-ответы различаются в зависимости от места
Домен может возвращать разные DNS-ответы людям в разных местах, и при этом ни один из ответов не будет ошибочным. DNS-провайдеры и CDN могут использовать географическую маршрутизацию или маршрутизацию с учётом задержки, чтобы направлять пользователей к региональной инфраструктуре. У рекурсивных резолверов могут быть разные кешированные значения, а корпоративные сети могут применять split-horizon DNS, чтобы сотрудники получали внутренний ответ, а публичный интернет видел другой. Поэтому адрес, который вы видите, зависит от имени хоста, типа записи, резолвера, расположения и времени. Один запрос не может отразить все возможные картины, поэтому при сравнении нужно сохранять этот контекст.
Географический DNS и DNS с учётом задержки
Провайдер с поддержкой геомаршрутизации оценивает каждый запрос и выбирает ответ по настроенным регионам, сетевым измерениям или политикам. Он может вернуть ближайший узел CDN или региональную точку приложения. Как правило, провайдер видит рекурсивный резолвер, отправивший запрос, а этот резолвер может находиться далеко от конечного пользователя или обслуживать множество пользователей. Некоторые системы используют EDNS Client Subnet, чтобы передать частичный сетевой контекст, но поддержка и поведение с точки зрения приватности различаются. Поэтому запрос из одного места не всегда описывает, что получает конкретный человек в этом месте через выбранного им интернет-провайдера или корпоративный резолвер.
| Причина | Почему ответ может отличаться |
|---|---|
| Geo DNS | Провайдер выбирает записи по региону резолвера или сети |
| CDN | Для разных мест запроса могут возвращаться разные узлы |
| Кеш | Резолверы обновляют данные в разное время в зависимости от TTL |
| Split horizon | Внутренние и публичные клиенты получают разные представления зоны |
| Failover | Провайдер меняет ответы после проверок работоспособности или событий политики |
Кеширование создаёт ещё один источник расхождений. Один резолвер может по-прежнему хранить прежний ответ, а другой уже получил новый. Уменьшение TTL не сокращает задним числом значение, которое уже закешировано со старым TTL. Локальные операционные системы и приложения тоже могут добавлять собственное поведение кеша. Если запись изменили недавно, зафиксируйте прежний TTL и время публикации изменения. Дайте кешам время истечь и запросите авторитативные серверы имён, чтобы проверить саму зону, прежде чем делать вывод, что обновление не сработало.
Как разобраться в расхождении
Сравните одно и то же имя хоста и тип записи через именованные резолверы и запишите, где и когда выполнялся каждый запрос. Проверьте авторитативные серверы имён, чтобы увидеть, что зона публикует сейчас. Если различаются только рекурсивные ответы, подумайте о возрасте кеша, политике резолвера или географии. Если расходятся авторитативные серверы, проверьте синхронизацию у провайдера и делегирование. Если внутренние и внешние пользователи видят разные значения, выясните, задумано ли split-horizon DNS намеренно. Наконец, проверьте саму конечную точку сервиса: разные DNS-адреса могут вести на исправные копии приложения, а одинаковые ответы могут одинаково не работать по причинам, не связанным с DNS.
- Записывайте резолвер, место запроса, имя хоста, тип записи, ответ и время.
- Сравнивайте авторитативные данные, прежде чем снова менять записи.
- Учитывайте кеширование по TTL и негативное кеширование после правок DNS.
- Проверяйте правила CDN и геомаршрутизации, которые намеренно меняют ответы.
- Проверяйте работоспособность сервиса независимо от разрешения имён.
Что разные ответы не доказывают
Разные публичные ответы сами по себе не означают, что DNS перехвачен, домен скомпрометирован или исходный сервер переехал. Это может быть нормальным поведением по замыслу. Точно так же совпадающие ответы не доказывают, что все посетители идут одним путём, ведь кеши и прикладной уровень могут отличаться. Ищите подтверждающие свидетельства: конфигурацию у провайдера, опубликованные уведомления о работах, известные диапазоны CDN и телеметрию приложения. Формулируйте выводы осторожно, особенно когда адрес принадлежит общей инфраструктуре, обслуживающей множество клиентов.
Чтобы разобраться в механизмах распределённых ответов, прочитайте о том, как CDN используют DNS и о DNS-балансировке нагрузки. Инструмент проверки домена даёт полезный снимок публичного DNS; если вы сравниваете картины, повторите тот же запрос через второй резолвер. Если хранить контекст запроса рядом с результатом, кажущееся противоречие превращается в свидетельство о политике маршрутизации, кешировании или конфигурации.
Сравнивайте ответы, не теряя контекст
Полезная таблица сравнения должна включать время запроса, адрес резолвера, расположение или сеть, имя хоста, тип записи, код ответа, TTL и значения ответа. Если результаты различаются, добавьте, каким является резолвер (публичным, корпоративным или управляемым провайдером) и использует ли домен CDN. Повторите запрос позже, чтобы определить, стабильна ли эта разница как политика или это временное расхождение кешей. Если один и тот же резолвер возвращает разные ответы в разное время, проверьте балансировку нагрузки и отказоустойчивое переключение по состоянию здоровья. Если два резолвера стабильно расходятся, изучите настройки геолокации или split-horizon. Такой контекст превращает «DNS работает непоследовательно» в конкретное наблюдение, которое DNS-провайдер может воспроизвести и объяснить. Сообщая о сравнении, не утверждайте, что один ответ глобально правильный, пока не подтвердили политику маршрутизации домена. Объясните, откуда пришёл каждый ответ: от авторитативного сервера или из рекурсивного кеша, и сохраните показанный вместе с ним TTL. Если CDN намеренно возвращает региональные точки, правильный вопрос состоит в том, исправна ли каждая точка в своём регионе, а не в том, возвращают ли все резолверы один и тот же адрес. Это различие не даёт ожидаемой схеме маршрутизации превратиться в эскалацию как сбой DNS.
Нужно проверить публичные DNS-адреса домена? Воспользуйтесь инструментом Domain IP Lookup.
Читайте также
Четыре уровня, проверяемые по порядку
DNS
разрешение имени
Транспорт
TCP-соединение
TLS
проверка сертификата
Приложение
ответ по HTTP
Как диагностировать ошибку «Не удаётся получить доступ к сайту»
Это общее сообщение браузера скрывает несколько несвязанных причин сбоя, и DNS — часто самое быстрое, что можно сначала подтвердить или исключить.
«Распространение» — это лишь истечение срока жизни кэшей
0 мин
вы сохраняете изменение
0-5 мин
DNS-хостинг обновляет данные
до конца TTL
старый ответ ещё в кэше
после TTL
новый ответ видят все
Ничего никуда не рассылается — каждый кэш просто перестаёт использовать свою копию
Что делать, если изменения DNS не вступают в силу
Вы обновили запись, подождали, а она всё ещё выглядит неверно. Прежде чем считать, что что-то сломалось, пройдите эти шаги по порядку.
Сколько обычно занимает проверка
Диагностика медленного DNS-разрешения
Медленно открывающийся сайт иногда оказывается медленным DNS-запросом. Как отличить одно от другого и что обычно становится причиной.