DNS‑петля: как сервер смотрит сам в себя и не находит выхода

В сфере искусственного интеллекта произошло заметное событие. Andrey_Biryukov 5 минут назад DNS‑петля: как сервер смотрит сам в себя и не находит выхода Средний 9 мин 7 Блог компании OTUS DevOps * Сетевые технологии * Системное администрирование * Туториал Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Проблемы с DNS могут сделать жизнь системного администратора намного «интереснее». Например, представим ситуацию: вы открываете браузер, вбиваете привычный адрес внутреннего портала — и видите бесконечную загрузку. Страница не открывается, вы пробуете другой внутренний сайт — тот же результат.

Технические детали

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

Но они чисты, процесс BIND также работает. Казалось бы, всё нормально. Но каждая попытка разрешить внешнее имя занимает десятки секунд, а иногда и вовсе заканчивается таймаутом.

И вы начинаете копать глубже…Как forwarder указывает на самого себяВ конфигурации BIND (named. conf) есть раздел options, где можно определить список forwarders — DNS‑серверов, которым локальный сервер будет пересылать запросы для доменов, которые он не обслуживает авторитативно. Типичная конфигурация выглядит так: ;Здесь всё правильно.

Отраслевые последствия

Сервер, не найдя ответа в своих зонах и кэше, отправляет запрос на публичные DNS Google и ждёт ответа. Если forwarders не отвечают, он (при forward first) попытается выполнить рекурсию самостоятельно, обратившись к корневым серверам. Проблема возникает, когда в списке forwarders оказывается он сам.

Например, в таком варианте: ;Или если в файле /etc/resolv. conf, который сервер читает через forwarder, первой строчкой указан nameserver 127. Что происходит дальше, напоминает классический «У попа была собака»: сервер получает запрос, не находит ответа в своих зонах, смотрит в список forwarders, видит там себя, отправляет запрос себе же.

Тот же сервер получает этот запрос и снова запускает процедуру поиска. В результате петля замкнулась. В документации CoreDNS эта проблема описывается так: «Чаще всего forwarding loop вызывается тем, что CoreDNS отправляет запросы напрямую самому себе — например, на адрес 127.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.