Архив метки: dns

Как МТС подменяет DNS-ответы для своих клиентов

Internet, Разное,

Один из самых простых вариантов проверки чего-нибудь сетевого «извне» на рабочем месте — проверить это на телефоне. Недавно возникла необходимость проверить доступен ли снаружи один из поддоменов компании и, как обычно, чтобы не лезть на внешние DNS-сервера, я решил воспользоваться одной из утилит под Android для получения информации от DNS-серверов (Ping & Net).

Проверка показала, что A-записи для домена есть, их две и указывают они на амазоновские айпишники, где у нас тоже есть часть сервисов. Начали разбираться и искать эти адреса, не смогли найти и решили все же сходить в наш DNS. Оказалось, что такого поддомена у нас нет во внешней сети!

Проверил ответ от гугловского DNS — тоже пусто. Решил попробовать спросить напрямую у DNS-серверов МТС, но не с телефона, а с рабочего ПК. Естественно, они отклонили запросы (сервера 134.17.1.1 и 134.17.1.0). Запрос несуществующего имени, отправленный напрямую к этим DNS-серверам с телефона из сети МТС, возвращает адреса A-записей 52.214.129.184 и 52.209.63.28. Соответственно, если вы пытаетесь зайти на любой несуществующий домен из сети МТС — у вас открывается прекрасная «информативная» рекламная страница МТС (portal.ncnd.mts.by) с (внезапно!) ошибкой 404 и кучей рекламного контента (который, на секундочку, тратит ваш трафик, если у вас не безлимит). ИМХО, такие действия вводят пользователей в заблуждение: ошибка 404 — совсем не то же самое, что «домен не найден».

В качестве одной «ложки меда в бочке дегтя» можно назвать то, что на этой же странице можно управлять данной «услугой». Т.е. отписаться от этого чудо-портала. После отписки DNS-сервера отвечают, что такого домена нет, но мобильные браузеры все равно каким-то образом редиректят на portal.ncnd.mts.by и при этом не могут его открыть. МТС, такой МТС…

Очень медленно грузится web-интерфейс Zabbix

bind, Zabbix, , ,

Утро началось как обычно: с проверки всех систем, отчетов и просмотра графиков заббикса. Вот только с последним возникла непонятная проблема. Он установлен на сервере, который является по совместительству веб-сервером для различных проектов. При попытке открыть страницу, браузер висел в ожидании каждого графика, да и страницы в целом секунд по 20-25. Просмотр вывода top не показал никакой нагрузки, ну т.е. совсем никакой — la около 0,3, загрузка процессора около 5%. Количество процессов вменяемое, никаких лимитов не превышено.

После сбора расширенных логов с nginx (именно он стоит в качестве фронтенда) с временем генерации страниц, становится понятно, что затык не в нем, а ниже, т.е. либо в апаче, либо в mysql. Лог медленных запросов mysql тоже не сказал ничего насчет таблиц заббикса. Сервер «боевой», поэтому включать дебаг и смотреть чем же занят все это время httpd и почему же загрузка процессора им равна 0 никак нельзя. Процессы httpd висят в состоянии kqread и не грузят процессор совсем.

Что удивительнее, другие сайты/приложения работали без задержек. Пришлось судорожно вспоминать все изменения, которые вносились в конфигурацию сервера в последнее время. Из всего, что было сделано, на ум приходила только настройка форвардинга в DNS-сервере bind. С целью уменьшения задержек и объема внешнего трафика, был настроен форвардинг запросов DNS на сервер провайдера. Казалось бы, причем тут DNS? Но после отключения форвардинга и перезапуска dns-сервера, заббикс загрузился быстро, как ни в чем не бывало. Подробный анализ всех логов выявил таймауты при обращении к DNS провайдера… Но как? Как это могло повлиять на загрузку веб-интерфейса заббикса?..