"Зачем нужен DNS" или "Почему сервер тормозит?".
"Доменная система имен (Domain Name System, DNS) - это распределенная
база данных, которая содержит информацию о компьютерах, включенных в сеть
Internet."(UNIX: руководство системного администратора Эви Немет и др.
Пер. с англ.)
Так начинается описание системы DNS в одной из лучших, на мой взгляд,
книг по UNIX. Подобные утверждения можно встретить и во многих других книгах
и статьях, посвященных DNS. Неудивительно, что в сознании людей система DNS
оказывается неразрывно связанной с Internet. К несчастью, такая ассоциация
оказывается крайне опасной для системного администратора. "Обращение к
интернет-ресурсам по символическим именам происходит нормально,значит с DNS
все в порядке" - администратор легко может впасть в подобное заблуждение
под влиянием этой устойчивой ассоциации.
Типичная ситуация. Загружен новый сервер, пробуем зайти на него используя
(ssh, ftp, pop3, smtp, telnet - недостающий протокол добавить ;-) ) с
соседней машины в локальной сети. Обнаруживаем, что соединения приходится
ждать пару минут... В чем дело? Одной из возможных причин может быть
неверная настройка DNS на сервере.
Дело в том, что установление соответствия между именами и ip-адресами
нужно не только пользователю. Многие программы - сервера пытаются
определить имя машины клиента по ее ip-адресу. Зачем? А чтобы в лог записать
- осуществлено, мол, соединение с машины с таким-то именем и таким-то ip. А
если не удалось ip-адрес в имя преобразовать, то записывают - имя клиента
определить не удалось, ip-адрес такой-то. Так работают, например, telnetd,
wu-ftpd, postfix, imapd... Встречаются, впрочем, и программы, которые так
не поступают, а пишут в логи только ip-адреса. Так работают, в частности,
apache, squid, popa3d.
Кроме того, утилиты, предназначенные для диагностики состояния сети, также
довольно часто по умолчанию пытаются выполнить трансляцию IP-адресов в символические
имена. Так работают, например, netstat, traceroute, ipchains.
Трансляцию адресов в них, впрочем, можно отключить, используя при вызове ключ -n
Утилита ping, как правило, по умолчанию подобную трансляцию не выполняет.
Впрочем из правила есть и исключения. О них дальше.
Посмотрим на примерах, к каким проблемам может привести некорректная настройка DNS:
1. При инсталляции Linux программа установки предложила ввести адрес DNS
сервера и при этом установила в этом поле значение по умолчанию, а Вы его
оставили. Или же сами ввели ip-адрес DNS-сервера и ошиблись.
Теперь Вы пытаетесь зайти с клиентской машины, к примеру, по ftp. Программа
ftp-server пытается определить имя машины клиента. Допустим, в /etc/hosts
его нет. Тогда она пытается использовать DNS. Шлет запрос к серверу на
несуществующий IP-адрес, ждет... снова шлет запрос... снова ждет...
наконец понимает, что больше пытаться не стоит, пишет в лог, что
установлено соединение с таким-то ip-адресом. Все, теперь можно работать,
но задержку в минуту - две таким образом вполне можно поиметь!
При этом, что характерно, если на этой же машине запустить apache, то с ним
клиенты будут работать без проблем.
А если,скажем, после установки соединения с клиентом вызвать, например, netstat -a,
то утилита отработает с изрядной задержкой. Все по той же причине - утилита долго
и безуспешно будет пытаться определить символическое имя клиента.
А вызов netstat -a -n отработает без всяких задержек.
(Это, пожалуй, самый простой случай)
2. Вариация на тему: DNS задан правильно, но вот сетевое соединение между
нашим сервером и сервером DNS ненадежное, пакетики теряются. Тот же
результат.
3. Более сложная ситуация: корпоративная сеть со шлюзом для выхода в интернет.
В сети две основные части: небольшая "демилитаризованная зона" с реальными IP-адресами и
"внутренняя" с IP-адресами из диапазона private address space согласно RFC 1597.
На стыке этих двух частей машина proxy и e-mail сервер. Она же - DNS-сервер для
"демилитаризованной зоны" и кэширующий DNS-сервер для интернет.
Используя собственный DNS, эта машина успешно разрешает
в символические имена IP-адреса интернет-диапазона.
А вот про адреса "внутренней" части сети система DNS "не знает".
Тут картина будет более сложной, поскольку DNS сервер умеет кэшировать ответы на запросы.
Как положительные, так и отрицательные. А через некоторое время кэш очищается.
Что же происходит? Как я понимаю, примерно следующее: При первом запросе на преобразование
в символическое имя IP-адреса из "внутренней" части сети сервер пробует сам
это сделать, не может, шлет запросы к корневым серверам через internet, они тоже не могут...
все это занимает значительное время и пользователь на машине-клиенте имеет изрядную задержку.
Но отрицательный ответ кэшируется, и пока кэш не очищен, задержка при повторном обращении становится
маленькой. Но если работает одновременно несколько клиентов, то может оказаться, что в момент повторного
запроса DNS сервер будет обрабатывать другой "неразрешимый" запрос... Вобщем,
получается крайне неприятная ситуация с "плавающей" ошибкой. Соединение
устанавливается то быстро, то медленно и никакой разумной закономерности
установить не удается.
Реальная история, кстати... Сколько я времени потратил, пока понял, в чем
дело... врагу такого не пожелаю. Вылечил, кстати, очень просто. Для всех машин
"внутренней" части сети были созданы фиктивные записи в файле /etc/hosts
сервера.Примерно так:
172.16.1.1 pc01.l1
172.16.1.2 pc02.l1
172.16.1.3 pc03.l1
Можно было бы, конечно, прописать и реальные имена.
Для удобства чтения логов.
Примечание: после написания первого варианта статьи я получил письма,
в которых предлагаются другие варианты решения этой проблемы без использования
/etc/hosts. Я попробую их на практике, а потом опишу.
4. Особенности конкретных дистрибутивов. В Black Cat Linux 6.2 (наверно и в
Red Hat 6.2, соответственно) утилита ping по умолчанию пытается произвести
трансляцию IP-адреса в символическое имя. Отменяется трансляция ключом
-n (справедливости ради скажу, что с ftp можно скачать обновленную версию пакета, в которой эта
особенность ликвидирована) Подвисание такого ping может означать не
отсутствие связи с проверяемой машиной, а проблему с трансляцией ее IP-адреса в
символическое имя. Попытка диагностирования проблем в сети с
помощью такого ping'а легко может поставить администратора в тупик.
(Ну что можно сказать по поводу подобной "доработки" ping? Воистину "благими
намерениями вымощена дорога в ад")
Приведенные примеры показывают: к DNS нельзя относиться пренебрежительно.
Если на сервере включено использование DNS, то следует внимательно следить,
чтобы ip-адреса всех машин-клиентов тем или иным способом разрешались в имена.
Несоблюдение этого принципа может привести к серьезным проблемам.
Что читать по поводу настройки DNS:
1. RTFM: man named, man named.conf, man resolver, man nslookup, man dig
2. Книги. Я пользовался книгой "UNIX: руководство системного администратора"
Эви Немет, Гарт Снайдер, Скотт Сиббас, Трент Р. Хейн
Пер. с англ. К.: BHV, 1997 Второе издание
3. Ресурсы интернет, которые я использовал:
Статьи в
Онлайновом журнале UNIXOiD:
Имена Интернет
Описание конфигурации BIND-8
Реализация виртуальных почтовых доменов
Статьи
Дмитрия Карпова - Postmaster'а МИСиС
Служба доменных имен
Пример настройки DNS сервера
Статьи
в журнале LAN
1999 г. номер 12 - BIND 8 на марше
1997г. номер 2 - Система доменов Internet
1997г. номер 3 - Настройка серверов имен DNS
Благодарности
Когда я разбирался с проблемой, описанной в п.3,мне помогли:
Russu V.F., router (список рассылки Black Cat),
Inna Antioufeeva (личная переписка)
Alexandr Kravchenko, Andrew Farmakovsky(список рассылки MLUG)
При написании версии 0.2 были учтены замечания:
Andrey Chesnokov, Василий Макаров, Golovin Dmitry
Спасибо!
История изменений:
версия 0.1 - 15 марта 2001г.
версия 0.2 - исправленная 25 марта 2001г.
Александр Жегалло
