Domain IP Lookup

Три причины, почему один домен отвечает по-разному

Геомаршрутизация

Свой edge-сервер в каждом регионе

Кэширование

Независимые TTL и кэши

Split-horizon

Другой ответ — так задумано

Устранение неполадок

Почему DNS-ответы различаются в зависимости от места

4 мин чтения

Домен может возвращать разные 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 — часто самое быстрое, что можно сначала подтвердить или исключить.

3 мин чтения

«Распространение» — это лишь истечение срока жизни кэшей

0 мин

вы сохраняете изменение

0-5 мин

DNS-хостинг обновляет данные

до конца TTL

старый ответ ещё в кэше

после TTL

новый ответ видят все

Ничего никуда не рассылается — каждый кэш просто перестаёт использовать свою копию

Устранение неполадок

Что делать, если изменения DNS не вступают в силу

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

3 мин чтения

Сколько обычно занимает проверка

1-10 мсОтвет из кэша, та же сеть — обычный случай
20-80 мсБез кэша, ближайший anycast-резолвер — всё ещё норма
500 мс+Стабильно так медленно — значит, что-то не так
Устранение неполадок

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

Медленно открывающийся сайт иногда оказывается медленным DNS-запросом. Как отличить одно от другого и что обычно становится причиной.

3 мин чтения