Отчёт об ошибке всегда одна и та же версия одного и того же. Работает здесь и не работает там. Работает по wifi, но не работает в сотовой сети. Работает у вас и не работает у клиента. Работало вчера. Ничего не менялось.
Когда сайт ведёт себя по-разному в зависимости от того, откуда вы смотрите, DNS — первое место для проверки — не потому что DNS хрупок, а потому что «DNS» — это не одна вещь. Ваш ноутбук, телефон, CI-раннер и клиент в другой стране — все спрашивают разные серверы, с разным программным обеспечением, разными политиками, разными кэшами, а в некоторых случаях — действительно разными ответами.
Вот карта того, кто на самом деле отвечает, и почему они не согласны.
Ваши настройки DNS, вероятно, не используются
Начнём с предположения, которое делают все: что резолвер, настроенный в сетевых настройках вашей ОС, и есть тот, кто отвечает на ваши запросы. Это становится всё менее верным уже годами.
Браузеры теперь делают собственный DNS. Firefox по умолчанию включает DNS-over-HTTPS в нескольких регионах, маршрутизируя поиск к резолверу по выбору Mozilla через зашифрованное соединение — полностью обходя резолвер вашей операционной системы, ваш роутер и вашего провайдера. Chrome делает нечто похожее, автоматически повышая уровень до зашифрованного DNS, когда обнаруживает, что настроенный вами резолвер это поддерживает.
Практическое следствие ошеломляет, когда вы сталкиваетесь с ним впервые: вы можете изменить настройки DNS в ОС, а браузеру будет всё равно. Вы очищаете кэш ОС, а браузер всё ещё разрешает старое значение, потому что кэш ОС никогда не был в пути. Вы указываете на внутренний резолвер для приватного имени хоста, а браузер не может его найти, потому что он спрашивает публичный резолвер на другом конце интернета.
Если имя хоста разрешается в терминале, но не в Chrome — или наоборот — это очень часто именно поэтому. Они разговаривают не с одним и тем же сервером.
Приложения тоже держат собственные кэши. Долго работающие процессы обычно разрешают имя хоста один раз при запуске и держат его. Некоторые языковые рантаймы исторически кэшировали результаты DNS на всё время жизни процесса по умолчанию. Сервис, работающий три недели, может использовать IP-адрес трёхнедельной давности, совершенно не завися от того, что вы меняете.
Раздельный горизонт: одно имя, два правдивых ответа
Многие организации используют раздельный горизонт DNS (split-horizon): один и тот же домен разрешается в разные адреса в зависимости от того, кто спрашивает. Внутри офиса app.company.com указывает на приватный адрес. Снаружи — на публичный.
Это намеренно и полезно, и это производит именно тот симптом, что в заголовке. На VPN работает, вне VPN — нет. По wifi нормально, в сотовой сети сломано. Ничего не настроено неправильно — вы получаете два разных, оба верных ответа из двух разных представлений, и какой из них вы получили, зависит от того, какого резолвера вы достигли.
Это становится по-настоящему запутанным, когда устройство частично находится во внутренней сети: VPN с раздельным туннелированием, или браузер, делающий DoH к публичному резолверу, пока ОС указывает на корпоративный. Теперь одно устройство получает внутренние ответы для одних запросов и внешние для других, по правилам, которые никто не может толком восстановить.
Что резолверы делают с вашими ответами
Не каждый резолвер — нейтральная труба. Некоторые меняют то, что вы получаете:
Перехват NXDOMAIN. Некоторые резолверы интернет-провайдеров перехватывают «домен не существует» и вместо этого возвращают IP-адрес страницы поиска или рекламы. С точки зрения клиента, опечатанный домен теперь разрешается, что ломает любое ПО, полагающееся на то, что NXDOMAIN означает то, что он значит — и тихо срывает логику отказа в почтовых серверах и приложениях.
Ограничение TTL. Резолвер может навязывать собственный минимум или максимум того, как долго он кэширует, независимо от того, что вы задали. Ваш тщательно выбранный TTL в 300 секунд становится тридцатью минутами, потому что такова политика. Именно поэтому миграции иногда занимают драматически дольше для подмножества пользователей.
Фильтрация и чёрные списки. Quad9, многие корпоративные резолверы и растущее число резолверов интернет-провайдеров отказываются разрешать домены, появляющиеся в фидах угроз. Если ваш домен попадает в список — из-за компрометации, общего IP с плохим соседом, или ложного срабатывания — он просто не будет разрешаться для этих пользователей, при этом прекрасно работая везде ещё. Вас не уведомят. Проверка того, находится ли ваш домен или IP в чёрном списке, стоит того, когда паттерн отказов коррелирует с конкретными сетями, а не с конкретными записями.
Проверка DNSSEC, или её отсутствие. Проверяющий резолвер отказывается возвращать ответ, который не может криптографически подтвердить. Непроверяющий отдаёт его без проверки. Так зона с истёкшей подписью работает из одних сетей и возвращает SERVFAIL из других — и разница коррелирует с программным обеспечением резолвера, а не с географией. Если сбои группируются странно, проверка цепочки DNSSEC быстро отделяет это от всего остального, потому что истёкшие подписи производят именно такое расхождение.
Та, что объясняет «медленно в некоторых странах»
Эта тонкая и недооценённая: EDNS Client Subnet, обычно сокращается до ECS.
Если вы используете CDN или любую настройку GeoDNS, авторитетный сервер выбирает ответ на основе того, где, по его мнению, вы находитесь. Но он не видит вас — он видит вашего резолвера. Если вы в Стамбуле, используя резолвер, ближайший экземпляр которого во Франкфурте, авторитетный сервер видит Франкфурт и возвращает европейский edge-узел.
ECS был разработан, чтобы это исправить: резолвер включает усечённую часть IP клиента в запрос, чтобы авторитетный сервер мог геолоцировать реального пользователя, а не резолвера.
Загвоздка в том, что поддержка намеренно варьируется. Публичный резолвер Google отправляет ECS. 1.1.1.1 от Cloudflare в основном нет, как намеренное решение в пользу приватности — они не хотят раскрывать клиентские подсети каждому авторитетному серверу.
Следствие: один и тот же пользователь, на том же соединении, направляется на разные узлы CDN в зависимости от того, каким публичным резолвером он пользуется. С ECS он получает ближайший узел. Без него он может получить узел на другом континенте. Сайт работает — он просто необъяснимо медленнее для некоторых людей, и с вашими DNS-записями нет вообще ничего не так.
Если вы гоняетесь за жалобами на региональную производительность, а ваш DNS «выглядит нормально», это сильный кандидат. Это также совершенно невидимо, если вы специально не ищете это.
У мобильных сетей свой собственный слой странностей
Сотовые сети добавляют осложнения, которых нет в проводных соединениях:
- Резолверы операторов кэшируют агрессивно и часто медленнее отражают изменения.
- Carrier-grade NAT означает, что ваш видимый исходный адрес разделяется с большим пулом других абонентов, что плохо взаимодействует с геолокацией на основе ECS и лимитированием скорости по IP.
- Private Relay и VPN-подобные функции на современных телефонах маршрутизируют DNS через инфраструктуру провайдера, так что DNS вашего пользователя происходит совершенно в другом месте, чем то, где он физически находится.
- Роуминг часто означает, что запросы DNS отвечаются резолвером домашнего оператора, в домашней стране, пока устройство находится в другом месте.
Последнее производит забавный случай, когда пользователь в одной стране получает ответы CDN для другой, потому что его оператор отвечает на DNS из дома.
Как это на самом деле диагностировать
Основной ход — перестать спрашивать «сломан ли DNS» и начать спрашивать «какой резолвер, и что он сказал».
-
Выясните, что на самом деле использует отказывающее устройство. Не то, что в настройках — то, что в пути. Проверьте, включён ли DoH в браузере; на телефоне проверьте, активна ли функция приватного релея или VPN.
-
Сравните ответы между резолверами. Если разные резолверы возвращают разные записи, проверьте одно и то же имя через несколько резолверов в разных сетях. Два паттерна, которые стоит различать: расхождение между старыми и новыми значениями означает кэширование (ждите TTL). Расхождение между разными значениями, каждое из которых внутренне последовательно, означает раздельный горизонт, GeoDNS или фильтрацию — и они не разрешаются ожиданием.
-
Спросите напрямую авторитетный сервер. Запросите источник истины и сравните. Если авторитетный ответ верен, а резолвер не согласен, проблема в пути резолвера — кэш, фильтр или проверка — а не в вашей зоне.
-
Проверьте, какой IP вы реально получаете. Если разные сети попадают на разные адреса, поиск по IP скажет вам, какому провайдеру и региону принадлежит каждый. Это немедленно отличает «GeoDNS работает как задумано» от «этого пользователя отправляют куда-то абсурдно».
-
Исключите DNSSEC и чёрные списки прежде чем трогать записи, поскольку оба производят чистые отказы в одних сетях и никаких в других.
Переосмысление
Не существует такой вещи, как «во что разрешается этот домен». Есть только «что вернул конкретный резолвер, в этот момент, с этим состоянием кэша, этой политикой проверки, этим списком фильтрации и этим представлением о вашем местоположении, этому клиенту».
Большую часть времени все эти ответы совпадают, поэтому упрощение обычно работает. Когда они перестают совпадать, вопрос не в том, сломан ли DNS — вопрос в том, чей DNS вы на самом деле рассматриваете, а на этот вопрос вы можете ответить примерно за пять минут, как только узнаете, что его нужно задать.