Содержание
Основному DNS-серверу Юникса, программе BIND (Berkeley Internet Name Domain) издавна присущи два недостатка:
Тем не менее, BIND продолжает оставаться самым популярным DNS-сервером Юникса, и как следствие, Интернета, поскольку Юникс является его движущей силой. Читая некоторые книги по сетевому администрированию, порой даже трудно понять разницу между терминами DNS (название сетевого протокола и основанной на нём службы) и BIND (название одной из программ-серверов, предназначенных для работы по этому протоколу).
Как и многое другое культовое ПО, BIND был первоначально разработан в 80-е годы в Университете Беркли. Таким образом, эта программа старше, чем WWW и прочие популярные на данный момент сервисы. Более того, её надёжное функционирование служит залогом их доступности, потому что в случае отказа DNS немногие пользователи сумеют запомнить и без ошибки ввести числовые IP-адреса нужных им серверов.
Как и для любого крупного проекта, объективной причиной проблем с безопасностью для BIND является возраст разработки: со временем исходный текст и настройки имеют обыкновение засоряться.
Не меньшим источником уязвимостей становятся устаревшие методики программирования: подпрограммы, копирующие данные без проверки переполнения буфера-приёмника, языки без встроенных средств обработки ошибок и т.д.
Но есть и ещё одна причина. BIND разрабатывается и распространяется под открытой лицензией. В этих условиях единственным источником дохода становится техническая поддержка. Техподдержка со стороны разработчика нужна преимущественно в момент установки очередной версии ПО. Протокол DNS давно оформился и существенным изменениям более не подвергается. Следовательно, поводом к появлению новых версий остаётся только исправление ошибок. Поэтому разработчикам становится выгодно исправлять ошибки постепенно, чтобы заставить потребителей устанавливать всё новые и новые версии, и при этом запутывать код, чтобы затруднить другим программистам создание конкурентных проектов на его базе.
Наиболее детально данную точку зрения изложил в своих статьях известный Интернет-скандалист (а также также весьма незаурядный и авторитетный программист!) доктор Д.Дж.Бернстайн (D. J. Bernstein). Ознакомиться с ними можно по адресу http://cr.yp.to/djbdns/blurb.html. Названия статей говорят сами за себя: «BIND, the Buggy Internet Name Daemon» и «How the BIND company makes money».
Кстати, описанная ситуация во многом применима и к другой программе-долгожителю, написанной в Беркли - почтовому серверу Sendmail. Однако его положение монополиста оказалось менее прочным: SMTP-серверы qmail (разработанный Бернстайном), postfix и exim приобретают всё больше приверженцев в Сети и в некоторых операционных системах (как, например, postfix в Mandrake Linux) успели стать основными.
Аналогичные попытки предпринимаются и в отношении BIND. Одной из альтернатив ему является djbdns, принадлежащий перу всё того же Бернстайна. djbdns, безусловно, надёжнее (первому, кто обнаружит в нём security hole, обещана премия $500), но весьма своеобразен в настройке. В частности, для его запуска требуются два вспомогательных пакета, написанных самим Бернстайном: daemontools для запуска системных сервисов и ucspi-tcp для запуска сетевых сервисов. Хотя это и не вызывает особых проблем, сама непривычность конфигурирования и необходимость администрировать ещё одну систему управления сервисами в дополнение к стандартной являются недостатками. В результате заставить BIND хоть сколько-нибудь существенно потесниться djbdns не смог. Ни одна операционная система не выбрала его в качестве основного, а в большинстве он не только не входит в комплект поставки на правах дополнения, но даже отсутствует в тестовом репозитарии.
Данная статья рассматривает ещё один DNS-сервер, призванный заменить BIND в небольших сетях -- программу dnsmasq.
Во-первых, DNS является клиент-серверной системой, то есть данными через сеть TCP/IP обмениваются компоненты двух типов:
!!! рисунок
Во-вторых, DNS является иерархической системой, то есть DNS-сервер, получив запрос на имя или IP-адрес, которые не принадлежат обслуживаемой им зоне, может направить его другому DNS-серверу, а затем отослать полученный ответ источнику запроса.
DNS-сервер, пересылающий запросы, которые не может обработать сам, называют форвард-сервером (forwarding server).
Ответ, полученный от сервера, непосредственно обслуживающего зону, к которой относится запрос, называют авторитетным (authoritative), а ответ от форвард-сервера - неавторитетным (non-authoritative).
Кэширующий сервер - это форвард-сервер, который запоминает пересылаемые запросы-ответы в собственном буфере, и получив такой же запрос повторно, вместо повторного обращения к серверу, от которого ответ был получен в первый раз, читает ответ прямо из буфера. Кэширование ускоряет работу самым существенным образом.
!!! рисунок
BIND и dnsmasq, имея монолитную конструкцию, способны работать в любом из перечисленных режимов. В противоположность им djbdns состоит из нескольких модулей, каждый из которых отвечает за одну задачу: форвардинг и кэширование выполняет модуль dnscache, а публикацию собственной зоны - модуль tinydns.
В-третьих, DNS является централизованной системой, то есть существует несколько компьютеров-серверов (т.н. корневых серверов DNS, root DNS servers), имеющих имена от A до M, на которые стекается содержимое всех зарегистрированных в мире зон, и к которым может подключаться любой DNS-клиент. Список этих серверов можно найти в Интернете по адресу http://www.root-servers.org/. !!! рисунок
В-четвёртых, DNS является не единственной системой, служащей для преобразования имён в адреса.
Вместо или в дополнение к обращениям на DNS-сервер рабочая станция может просматривать небольшую таблицу, хранящуюся в файле hosts. В ОС Юникс он находится в каталоге /etc, а в Windows - где-то в глубине системного каталога. Каждая строка имеет следующий формат:
IP-адрес ИмяУзла [ЕщёИменаЭтогоУзла...]
Как правило, файлы hosts используются в следующих случаях:
Исторически сложилось, что за просмотр файла hosts так же отвечает ресолвер. Таким образом, общее количество настроечных файлов, которыми пользуется ресолвер, равно трём:
Несколько лет назад Microsoft разработал собственную альтернативу DNS, называвшуюся WINS (Windows Internet Naming System, Система Интернет-имён Windows). Будучи несовместимым с DNS, WINS отличался от него двумя усовершенствованиями:
Начиная с Windows 2000, Microsoft отказалась от WINS в пользу т.н. динамического DNS (dynamic DNS, или DDNS), о котором речь идёт ниже, а для дополнительных атрибутов использует на DNS-сервере записи TXT-типа, предназначенные для хранения произвольной текстовой информации.
Упрощённый протокол доступа к электронным каталогам, или Light-Weight Directory Access Protocol, предназначен для доступа к иерархически упорядоченным текстовым данным. Каждая единица данных (т.н. запись, или record) содержит некоторое количество текстовых полей. Состав полей в записях, их имена, типы и дополнительные ограничения определяются схемами каталога (LDAP scheme), причём одна и та же запись может хранить данные сразу по нескольким схемам.
Способ хранения данных зависит от сервера. Например, Windows 2000 Server хранит доступную через LDAP информацию в системе Active Directory, а OpenLDAP - в SQL-базе (в качестве одного из вариантов).
Безусловно, основным предметом хранения в LDAP является информация о пользователях - взгляните, например, на закладку «Служба каталогов» в учётных записях Microsoft Outlook. Но наряду с этим LDAP в состоянии хранить неким стандартным образом и сведения о компьютерах. В зависимости от ПО, рабочая станция может уметь читать эти данные как напрямую через LDAP-протокол, так и через DNS-протокол от сервера DNS, снабжённого соответствующим backend-модулем. Подробнее об этом можно прочесть в документе LDAP Implementation Howto на сайте Linux Documentation Project.
Естественно, приложениям, нуждающимся в определении сетевых имён, нет необходимости самостоятельно опрашивать каждую из перечисленных подсистем. Вместо этого стандартные функции распознавания сведены в системную библиотеку, называемую NSS (Name Services Switch, переключатель сервисов имён). Имена модулей, предоставляющих интерфейсы к конкретным системам, которые следует вызывать в том или ином случае, библиотека читает из настроечного файла /etc/nsswitch.conf.
Например, запись «hosts: files dns» означает, что распознавание компьютерных имён и адресов должно производиться сначала через файл /etc/hosts, а в случае неудачи - через DNS; запись «passwd: files ldap» предписывает проверять имена и пароли пользователей через файл /etc/passwd и затем на сервере LDAP. !!! рисунок
DHCP (Dynamic Host Configuration Protocol, протокол динамической настройки компьютеров) тоже в определённом смысле является протоколом сетевого распознавания, но в отличие от DNS сообщает IP-адрес рабочей станции не всем компьютерам, а только ей самой -- в момент запуска рабочая станция посылает в сеть широковещательный запрос и получает от DHCP-сервера необходимые сетевые реквизиты. Назначаемый для неё DHCP-сервером IP-адрес может быть как фиксированным, зависящим от MAC-адреса сетевой карты или имени рабочей станции, так и первым свободным из зарезервированного для DHCP диапазона. Выбор варианта принадлежит системному администратору и, как правило, ленивые или малоквалифицированные администраторы предпочитают второй вариант, как более простой.
Вследствие этого в сети будут присутствовать компьютеры, IP-адрес которых заранее неизвестен и поэтому не может быть прописан в таблице на DNS-сервере. Как следствие, остальные компьютеры не смогут обращаться к ним по сетевому имени. Единственный способ обойти это препятствие - заставить DHCP-сервер каким-то образом оповещать DNS-сервер (как наиболее распространённую службу распознавания адресов) о назначаемых IP-адресах. Соответствующее дополнение к DNS-протоколу получило обозначение Dynamic DNS.
Естественно, возникает проблема безопасности: если какая-то программа способна обновлять свои данные по указаниям извне, необходимо застраховаться от ситуаций, когда эти указания исходят от постороннего источника (в частности, от злоумышленника, решившего подделать таблицу имён). В случае с DDNS это достигается следующим образом:
Неприятной особенностью сетевых настроек на рабочей станции (не на DNS-сервере) является необходимость прописывать одни и те же данные в нескольких местах (хотя это отчасти компенсируется настроечными утилитами). Рассмотрим расположение некоторых настроек в операционной системе RedHat Linux.
Имя и IP-адрес рабочей станции указываются в файлах /etc/hosts и /etc/sysconfig/network. DNS-домен, которому принадлежит рабочая станция, и обслуживающий его DNS-сервер указываются в /etc/resolv.conf (файл настроек DNS-клиента, т.е. библиотеки resolver) и /etc/sysconfig/network.
Когда утилита PPP устанавливает dialup- или VPN-соединение с провайдером, провайдер может прислать адреса DNS-серверов, которыми следует пользоваться клиенту. Эти адреса PPP записывает в /etc/ppp/resolv.conf и временно добавляет в конец /etc/resolv.conf. Этот же файл модифицирует и программа-клиент DHCP, когда получает от DHCP-сервера IP-адрес DNS-сервера и имя DNS-зоны. Оригинальный файл при этом переименовывается в /etc/resolv.conf.sv.
На сервере настройки повторяются между многими сетевыми сервисами. Например, файл настроек ISC DHCPD (DHCP-демон, написанный Internet Software Consortium), /etc/dhcpd.conf дублирует в себе адрес, маску и DNS-имя локальной сети, а также IP-адреса маршрутизатора и DNS-сервера.
После того, как на компьютере инсталлирован BIND, эти же самые данные требуется многократно вводить снова, но уже в его файлах настройки. При этом некоторые данные дублируются не только между BIND'ом и системой, но и внутри самого BIND'a! В частности, соответствия имён IP-адресам и IP-адресов именам (т.н. прямая и реверсивная зоны) - это две отдельных таблицы, расположенные в разных файлах.
Необходимость помнить, какие настройки где продублированы, придаёт работе системного администратора оттенок паранойи.
Каких настроек потребует dnsmasq? Ответ: никаких. Все необходимые для работы сведения он возьмёт из уже существующих файлов:
Таблица имён и IP-адресов для собственной зоны формируется из двух источников:
Таким образом, DNS-сервер под управлением dnsmasq является работающим немедленно после установки!
В большинстве Юникс-совместимых операционных систем принято сопровождать каждый демон (т.е. каждую запускаемую при старте системы постоянно работающую в фоновом режиме сервисную программу) небольшой программой-сценарием, выполняющей его запуск, остановку, проверку состояния и прочие обслуживающие действия. В ALTLinux, так же как и в прочих Линуксах, ведущих родословную от RedHat, эти сценарии находятся в каталоге /etc/rc.d/init.d. Для запуска сценариев предусмотрена команда service, например:
service dnsmasq status
Файлы настроек для сервисных сценариев у RedHat принято размещать в каталоге /etc/sysconfig. В нём хранятся настройки двух типов:
Доопределяя здесь настройки сервиса, основные настройки (как правило, расположенные в файле /etc/ИмяСервиса.conf или каталоге /etc/ИмяСервиса) рекомендуется без веских оснований не трогать, то есть оставлять их в том виде, в каком они распространяются составителями дистрибутива:
Хотя путь /etc/resolv.conf общепринят, /etc/sysconfig/dnsmasq содержит параметр RESOLV_CONF, позволяющий его переопределить. Приятное отличие сборки dnsmasq для ALTLinux от сборок в других ОС заключается в подготовительной работе, которую по отношению к данному файлу производит сценарий запуска сервиса.
Во-первых, после запуска dnsmasq следует, узнав из /etc/resolv.conf IP-адрес вышестоящего DNS-сервера, исправить его на 127.0.0.1 (IP-адрес локального компьютера), чтобы с этого момента DNS-ресолвер обращался с запросами не в сеть, а к dnsmasq. Во-вторых, следует отучить PPP дописывать в конец /etc/resolv.conf адреса DNS-серверов провайдера, полученные в момент соединения.
С этой целью сценарий запуска dnsmasq копирует /etc/resolv.conf в /etc/resolv.conf.dnsmasq, а оригинальный файл исправляет следующим образом:
При остановке сервиса проделывается обратная операция, причём /etc/resolv.conf либо затирается содержимым /etc/resolv.conf.dnsmasq, либо, если в нём обнаружены изменения, переименовывается в /etc/resolv.conf.dnsmasqnew.
Чтобы иметь доступ к DNS-серверу, адрес которого сообщается динамически PPP или DHCPC (DHCP client), dnsmasq будет напрямую отслеживать файл, заданый в /etc/sysconfig/dnsmasq параметром PPP_RESOLV_CONF -- по умолчанию /etc/ppp/resolv.conf. PPP записывает сюда свои сведения при включённой в /etc/ppp/options опции usepeerdns. В случае с DHCPC файлом для слежения через PPP_RESOLV_CONF должен быть cделан /etc/dhcpc/resolv.conf.
В ALTLinux при инсталляции сетевых сервисов принято по умолчанию разрешать к ним доступ только с того компьютера, на котором они запущены. Подразумевается, что администратор, произведя настройку сервиса, расширит доступ к нему до требуемого уровня. В /etc/sysconfig/dnsmasq за это отвечают параметры listen-address=127.0.0.1 и bind-interfaces. Типичной ошибкой многих начинающих администраторов является полное отключение данной настройки вместо её аккуратного редактирования. Таким образом в сети появляются прокси-серверы, доступные любому желающему, общедоступные файловые архивы с закрытым коммерческим ПО и Веб-серверы, на которых можно получить полный список пользователей в организации. Хотя dnsmasq не хранит столь важную информацию и не замечен в уязвимостях, как минимум не следует давать к нему доступа из внешней сети (*).
Минимальная настройка сервера DHCP в dnsmasq.conf сводится к одной директиве, dhcp-range, которая задаёт диапазон IP-адресов для назначения клиентам. Прочие сообщаемые клиенту параметры - маска сети, имя DNS-домена, имя DNS-сервера, адрес маршрутизатора - формируются тем же образом, что и настройки сервера DNS, то есть читаются из общесистемных настроек. В дополнение к dhcp-range существует ещё несколько директив с общим префиксом dhcp-, позволяющих, во-первых, задавать дополнительные параметры для передачи клиентам (например, адрес TFTP-сервера и имя файла с ядром Linux для бездисковой сетевой загрузки) и во-вторых, создавать группы параметров для передачи отдельным клиентам или группам клиентов.
Поскольку два сервера, DNS и DHCP, объединены в одной программе, не возникает проблем с обменом сведениями между ними -- что знает один, немедленно узнаёт и второй. Например, как только DHCP назначает клиенту IP-адрес, данный адрес немедленно появляется в таблице сервера DNS. И наоборот, если запрашивающий DHCP-настройки клиент имеет имя, присутствующее в таблице имён DNS, ему сообщается IP-адрес, указанный для этого имени в таблице.
Если вместо встроенного в dnsmasq DHCP-сервера запущен отдельный сервер DHCP, а dnsmasq является только сервером DNS, то для обновления таблицы имён вместо вместо связывания двух серверов через сокет или именованный канал используется более простой трюк: dnsmasq следит за изменениями в файле /var/lib/dhcpd/dhcpd.lease, куда DHCP-сервер в текстовом виде записывает копии настроек, назначенных клиентам. Читая этот файл, dnsmasq на лету обновляет свою таблицу. Примитивно? Зато надёжно и просто.
Безусловно, у такого варианта есть ограничения, пусть и незначительные. Во-первых, обе программы требуется запускать на одном и том же компьютере, чтобы они видели один и тот же файл. Во-вторых, файл dhcpd.lease не является чем-то стандартным и генерируется всего одной известной программой-сервисом DHCP - ISC DHCP Daemon. Которая, впрочем, не имеет в большинстве ОС никакой альтернативы. В-третьих, автономный DHCP-сервер имеет отдельные настройки, которые придётся поддерживать в соответствии общесистемным вручную.
Для обслуживания корпоративной сети dnsmasq не годится как минимум по двум причинам.
Во-первых, стандарт протокола DNS предусматривает поддержку одной зоны несколькими DNS-серверами, с репликацией (синхронизацией) изменений между ними. Благодаря этому становится возможным повысить как производительность, так и надёжность DNS-сервиса.
Поддержки репликаций в dnsmasq нет, и модифицировать таблицу имён по командам DNS-протокола он не умеет. Единственный непроверенный способ не слишком элегантно обойти данное ограничение -- попытаться синхронизировать файлы hosts (и dhcpd.lease?) через rsync или cvs.
Во-вторых, DNS-сервер, разрешая клиентам обращаться к нему в принципе, должен уметь ограничивать им доступ к тем или иным данным в зависимости от их IP-адресов (этот механизм контроля называется IP-авторизацией). Назначенный ресурсу список клиентов и выданных им разрешений обозначается термином ACL, Access Control List, т.е. список прав доступа. ACL на главном DNS-сервере большой организации могут выглядеть так:
В отличие от BIND версии 8 и старше, dnsmasq не позволяет разграничивать доступ к данным подобным образом. Это означает, что одной копии dnsmasq следует поручать обслуживание ровно одной категории пользователей.
Например, если dnsmasq отвечает за поддержку публичной зоны, должен быть полностью отключён форвардинг, так как, несмотря на необходимость внутренним клиентам, форвардинг должен быть недоступен извне. Более предпочтительным представляется не поручать dnsmasq эту задачу вообще, а воспользоваться услугами провайдера или бесплатного публичного DNS-сервиса наподобие www.xname.org.
Если dnsmasq обслуживает локальных клиентов, содержа локальную зону и осуществляя форвардинг в Интернет, он должен быть закрыт от запросов из внешнего мира одним из двух способов:
Второй вариант безусловно проще и надёжнее; для его поддержки в dnsmasq.conf имеются параметры interface, except-interface, listen-address и крайне полезный bind-interfaces. Если же на компьютере имеется всего одна сетевая карта и один логический сетевой интерфейс с одним IP-адресом, селекция по сетевому интерфейсу становится невозможна и используется первый вариант, отсекающий запросы к сервису по IP-адресу отправителя.
Нишей, в которой dnsmasq нет равных, являются микро-дистрибутивы Linux для организации маршрутизаторов, файрволов и модемных шлюзов, такие как вмещающиеся на одну дискету FreeSCO и FloopyFW.
Представляет интерес использование dnsmasq в следующем над однодискетными роутерами классе сетевых решений, к числу которых относятся, например, ALTLinux SOHO Server (SOHO расшифровывается как Small Office/Home Office) и Mandrake MNF (Multi-Network Firewall). Общими характеристиками таких систем являются:
Различные участники ALT Linux Team пробуют сейчас использовать dnsmasq в своих проектах, и после того, как будет собрано должное количество положительных отзывов, возможно его включение в официальную версию SOHO Server.
Что же касается универсальных дистрибутивов, то для большинства свободных ОС (Gentoo Linux, FreeBSD, RedHat и т.д.) сборки dnsmasq уже существуют, хотя ни один дистрибутив не отдаёт пока этой программе предпочтения перед BIND. К их числу относится и ALTLinux - текущий репозитарий этой ОС, называемый Sisyphus, содержит в своей коллекции, насчитывающей сейчас более 6500 пакетов, пакет с очередной версией dnsmasq.