Михаил Фленов СанктПетербург бхвпетербург 2010 удк 681 06 ббк 32. 973. 26018. 2 Ф69
 Скачать 3.69 Mb.
|
|
Глава 11 DNS-сервер Каждый компьютер, подключенный к сети, должен иметь свой адрес, чтобы его можно было найти и обмениваться с ним данными. Это похоже на теле- фонные сети. Чтобы кому-нибудь позвонить, нужно знать его номер телефо- на , иначе коммутатор не сможет понять, с кем вас соединить. Когда вы хотите получить WEB-страничку с сервера, то необходимо знать его адрес. В запросе нужно указать свои координаты, чтобы сервер знал, куда вернуть требуемую страничку. Здесь просматривается аналогия с почтой. Отправляя письмо, вы указываете адрес, а если хотите, чтобы вам ответили, то должны указать и обратный адрес. В эпоху зарождения сетей компьютеров в них было мало, поэтому для адре- сации был выбран самый простой вариант — числа. Я думаю, что если бы Интернет появлялся только сейчас, то приняли бы точно такое же решение. Но с увеличением количества компьютеров сетевая общественность стала осознавать , что помнить больше 20 адресов невозможно, поэтому было при- нято решение найти какой-либо способ, упрощающий запоминание. Изменять принцип нумерации было поздно, да и выбранная система IP- адресов очень удобна для обработки на программном уровне компьютерами и сетевыми устройствами. Немного поколдовав, умные люди придумали соз- дать централизованную базу данных, устанавливающую соответствие IP- адресов и символьных имен. Таким образом, пользователь оперирует имена- ми узлов, а программа находит нужный IP-адрес в базе DNS и уже по нему соединяется с другим компьютером или сервером. Этот метод очень сильно упростил задачу. Раньше, чтобы найти сервер, нуж- но было четко знать его IP-адрес. Теперь в простой ситуации можно обойтись даже без поисковых систем типа Yahoo или Google. Например, если нужен сайт корпорации Microsoft, то можно попробовать набрать в браузере адрес www.microsoft.com. Таким образом, WEB-серверы фирм чаще всего можно найти просто по их имени, и не надо запоминать лишнюю информацию. Глава 11 346 11.1. Введение в DNS Первое время преобразование IP-адресов в имена и обратно происходило с помощью простого текстового файла, по которому и проводилось сопос- тавление параметров. В Linux за это отвечает файл /etc/hosts. Несмотря на его слабости и неудобства в сопровождении, в малых сетях возможностей такого файла достаточно. С расширением сети понадобился новый способ хранения соответствий. На смену файлам пришла система доменных имен (DNS, Domain Name System), предназначенная для преобразования символьного имени в IP-адрес и наоборот. Ее преимущества могут проявляться не только в Интернете, но и в локальных сетях с достаточно большим количеством компьютеров. Внедрение DNS выявило еще одно преимущество этой системы — под одним и тем же IP-адресом могут скрываться несколько узлов. Например, хостинго- вые компании на одном сервере могут содержать несколько сайтов. Сервер DNS — это большая база данных, в которой хранятся данные о соот- ветствии имен узлов и IP-адресов. Самое главное, что эта информация децен- трализована , и в Интернете существуют тысячи таких серверов. База данных имеет иерархическую структуру, вершиной которой является точка (.). Это наподобие знака / в файловой системе Linux, обозначающего корневую директорию. На первом уровне идут домены типа com, org, net, gov, ru, de и т. д. Ниже находятся имена доменов второго уровня. Пример описанной структуры приведен на рис. 11.1. . com org net ru gov redhat cydsoft linux Рис . 11.1. Иерархия доменов В качестве точки раньше выступал единственный сервер, который отвечал за корневую систему. Но однажды этот сервер оказался недоступен, и весь Интернет парализовало. С тех пор было принято решение использовать несколько серверов и распределенную систему. DNS- сервер 347 Допустим , нужно найти IP-адрес сервера www.flenov.info. Имя разбирается справа налево. Сначала направляется запрос к корневому DNS-серверу, и он отвечает , кто обслуживает домен info. Затем на найденном сервере выполня- ется запрос на поиск домена с именем flenov. Если такой найден, то мы по- лучим адрес DNS-сервера, который обслуживает flenov.info. И уже ему на- правляется запрос на получение адреса домена www.flenov.info. Результатом будет IP-адрес сервера, которому присвоено имя www.flenov.info. Все эти действия происходят прозрачно для конечного пользователя, и когда вы набираете в браузере адрес, то никогда не увидите всех этих тонкостей. О том, что идет поиск IP-адреса по имени, можно узнать только по подсказке, которая высвечивается в строке состояния обозревателя. В сети есть множество кэширующих серверов, в принципе, выполняющих свои функции автоматически. Достаточно только его установить, сделать основные настройки и запустить. Кэширующие серверы обмениваются ме- жду собой информацией и позволяют найти любой адрес на ближайшем узле , не обращаясь к основной базе данных. Например, у вашего интернет- провайдера чаще всего есть свой DNS-сервер. Когда вы обращаетесь на ка- кой -нибудь символьный адрес, то запрос сначала идет на сервер провайде- ра , затем по цепочке передается другому серверу, и так до тех пор, пока нужная запись с IP-адресом не будет найдена, если, конечно же, имя указа- но верно. Таким образом, адрес запрашиваемого имени может быть полу- чен от ближайшего DNS-сервера, в кэше которого сохранилась необходи- мая информация. Серверы DNS могут и, наоборот, по IP-адресу сказать нам его символьный адрес . В этом случае IP тоже переворачивается. Например, если нужно узнать имя сервера 190.1.15.77, то в запросе к DNS будет виден адрес 77.15.1.190 и добавлен суффикс in-addr.arpa: 77.15.1.190.in-addr.arpa. 11.2. Локальный файл hosts Мы уже знаем, что изначально для сопоставления имен и адресов использо- вался файл /etc/hosts. Это текстовый файл с записями типа: 127.0.0.1 localhost.localdomain localhost 192.168.77.1 FlenovM Каждая строка — это соответствие IP-адреса его имени. По умолчанию в файле будет всего две строки, пример которых приведен выше. Пер- вая — это петля. Напоминаю, что во всех компьютерах имя localhost и IP- адрес 127.0.0.1 указывают на текущую машину. Это значит, что если Глава 11 348 нужно выполнить ping, адресовав запросы на локальный компьютер, можно написать ping 127.0.0.1 Во второй записи устанавливается соответствие между заданным для вашего сетевого интерфейса IP-адреса и символьным именем. В данном случае моей сетевой карте присвоен адрес 192.168.77.1, и ему соответствует имя FlenovM. Это значит, что при выполнении команды ping можно указывать или IP- адрес , или имя компьютера. Следующие две команды идентичны: ping 192.168.77.1 ping FlenovM При выполнении второй команды сначала происходит обращение к файлу /etc/hosts, который вернет программе адрес 192.168.77.1, и уже на него на- правится эхо-запрос. А что будет использоваться для поиска адреса первым: файл /etc/hosts или DNS-база данных? Это зависит от настроек ОС. Посмотрим на файл /etc/host.conf. В нем находится строка: order hosts,bind Директива order как раз и задает порядок просмотра. В данном случае на первом месте находится файл /etc/hosts, и только после этого будет запущена команда bind для выполнения запроса к DNS-серверу. Что это нам дает? А то, что можно увеличить скорость доступа к основным серверам. Допус- тим , что вы каждый день посещаете сайт www.redhat.com. При этом каждый раз происходит запрос к DNS-серверу, что может приводить к задержке в па- ру секунд перед началом загрузки страницы. Чтобы ускорить этот процесс, можно вручную прописать в файл /etc/hosts следующую запись: 95.100.0.112 www.redhat.com В Н И МА Н И Е ! Адрес 95.100.0.112 действительно соответствует сайту www.redhat.com на момент написания книги , но может измениться Если сайт по каким-либо причинам перестал загружаться, то необходимо удалить соответствующую запись из файла hosts, и с помощью команды ping redhat.com проверить связь с сервером, а заодно узнать его адрес. В ответ на эту директиву на экране обязательно отображается реальный IP-адрес, с ко- торым происходит обмен эхо-сообщениями. Благо IP-адреса у большинства сайтов изменяются редко, и, один раз добавив такую запись в локальный файл /etc/hosts, можно сэкономить достаточно много времени и нервов в случае проблем с DNS-сервером, потому что запроса к нему не будет. DNS- сервер 349 11.3. Внешние DNS- серверы Если в локальном файле /etc/hosts не найдено записи о нужном имени, то компьютер должен запросить эту информацию у DNS-сервера. Для этого нужно знать IP-адрес этого самого сервера. Как система его узнает? Из файла /etc/resolv.conf, который должен выглядеть примерно следующим образом: search FlenovM domain domain.name nameserver 10.1.1.1 nameserver 10.1.1.2 В первой строке находится команда search с параметром (сервер поиска имени хоста). В вашем файле, скорей всего, есть эта запись, и в качестве сер- вера стоит имя вашего компьютера. В этом параметре может быть перечис- лено несколько серверов, разделенных пробелами или символами табуляции. Например : search FlenovM MyServer Поиск на локальном сервере происходит достаточно быстро, а вот на удален- ных — может отнять достаточно много времени. Вторая строка содержит команду domain с параметром. Пользователи иногда любят задавать имя компьютера без указания домена, например redhat вместо redhat.com. Вы должны использовать полное имя узла. Чаще всего этот пара- метр настраивается в локальных сетях со специфичным именем домена. Оставшиеся две строки содержат команду nameserv с параметром. Это внеш- ний DNS-сервер, которому будут направляться запросы. В системе их может быть несколько (на данный момент для большинства дистрибутивов не бо- лее 3). Они будут опрашиваться в порядке перечисления в файле, пока иско- мый адрес не будет найден. В большинстве случаев достаточно и одного сервера, потому что все они работают рекурсивно. Но я рекомендую указывать два. Бывают случаи, когда один DNS-сервер выходит из строя, и тогда второй спасает положение и вступает в работу. 11.4. Настройка DNS- сервиса В настоящее время наиболее распространенным сервисом DNS для Linux яв- ляется bind. Для этого сервиса существует программа bindconf, которая имеет графический интерфейс и проста в использовании. Зайдите в графическую оболочку и в консоли выполните команду: bindconf & Глава 11 350 Знак & говорит о том, что, запустив программу, консоль не должна дожидать- ся ее завершения. Это очень удобно при запуске графических утилит, чтобы они не останавливали работу консоли. Учтите, что если закрыть окно консо- ли , то все программы, запущенные с ключом & , тоже закроются. На рис. 11.2 изображено запущенное приложение для настройки DNS- сервиса . В центре показано окно, которое появляется по нажатию кнопки Добавить . Как видите, достаточно только выбрать тип зоны и ввести имя домена , и все готово. Рис . 11.2. Приложение для настройки сервиса DNS Несмотря на наличие простой графической программы, мы рассмотрим кон- фигурационные файлы, которые могут использоваться сервисом DNS. Их прямое редактирование позволит сделать более тонкую настройку, и вы луч- ше будете понимать процесс работы DNS. Настройка DNS-сервера начинается с файла /etc/named.conf. Пример его со- держимого приведен в листинге 11.1. DNS- сервер 351 Листинг 11.1. Пример содержимого файла /etc/named.conf options { directory "/var/named/"; }; zone "." { type hint; file "named.ca"; }; zone "sitename.com" { type master; file "sitename.zone"; }; zone "10.12.190.in-addr.arpa" { type master; file "10.12.190.in-addr.arpa.zone"; }; В данном примере файл разбит на четыре раздела, каждый из которых имеет следующий формат: тип имя { Параметр1; Параметр2; … }; Давайте разберем назначение разделов. Первым идет options : options { directory "/var/named/"; }; В фигурных скобках только один параметр — directory , который указыва- ет на домашнюю директорию DNS-сервера. Все его файлы будут распола- гаться там. Остальные разделы имеют тип zone , и через пробел в кавычках стоит имя зоны . В каждом из них по два параметра: type (определяет тип зоны) и file (файл, в котором содержится описание). Глава 11 352 Самая первая зона в нашем примере — zone "." . Что это за зона в виде точ- ки ? Вспомните устройство DNS, которое мы рассматривали в начале главы. В базе данных DNS так обозначается корень. Получается, что раздел описы- вает корневую зону. Тип зоны hint , то есть хранятся лишь ссылки на DNS- серверы . Так как это корневая зона, то и ссылки будут на корневые серверы. В параметре file указывается имя файла, содержащего все ссылки на корне- вые серверы. В системе этого файла может и не быть, потому что информа- ция в нем может изменяться, и лучше всего получить последнюю версию с сервера internic.net. Для этого выполните команду: dig @rs.internic.net . ns > named.ca А можно скачать этот файл непосредственно с FTP-сервера Internic по адресу ftp://ftp.rs.internic.net/domain/named.root. Этот файл нужно поместить в директорию /var/named. Перейдем к следующему разделу zone "sitename.com" . Здесь описывается зона sitename.com. Тип записи master , значит ваш DNS-сервер будет глав- ным , а все остальные будут только сверяться с ним и кэшировать информа- цию . Сведения об этой зоне будут храниться в файле sitename.zone рабочей директории . В нашем случае это /var/named. Следующая зона описывает обратное преобразование IP-адресов 190.12.10.* в имена. Тип записи — снова master , и в последней строке указан файл, где будет находиться описание зоны. 11.5. Файлы описания зон Теперь посмотрим, что у нас находится в директории /var/named. Судя по файлу конфигурации /etc/named.conf, у нас здесь должно быть три файла: named.ca — хранит ссылки на корневые серверы. Этот файл просто заби- рается с сервера internic.net, поэтому его редактировать не стоит, и даже не будем на нем останавливаться; sitename.zone — отвечает за преобразование имени sitename.сom в IP- адрес ; 10.12.190.in-addr.arpa.zone — отвечает за преобразование адресов сети 190.12.10.* в имена. Файл sitename.zone может выглядеть следующим образом: @ IN SOA ns.sitename.com root.sitename.com ( 1 ; serial 28800 ; refresh 7200 ; retry DNS- сервер 353 604800 ; expire 86400 ; ttl ) IN NS ns.sitename.com. IN MX 10 mail.sitename.com. ns A 190.12.10.1 mail A 190.12.10.2 Разберем основные типы записей, которые используются при конфигуриро- вании DNS: SOA (Start of Authority, начало полномочий) — основная информация, ко- торая включает в себя почтовый адрес администратора, а также время жизни записи в кэше, данные о частоте ее обновления и др.; A (Address, адрес) — доменное имя и IP-адрес компьютера; CNAME (Canonical Name, каноническое имя) — синоним для реального до- менного имени, которое указано в записи типа A; PTR (Pointer, указатель) — отображает доменное имя по его IP-адресу; TXT (Text, текст) — дополнительная информация, которая может содер- жать любое описание; RP (Responsible Person, ответственное лицо) — адрес E-mail ответственно- го за работу человека; HINFO (Host Information, информация о хосте) — информация о компьюте- ре , такая как описание ОС и установленного оборудования. В целях безопасности записи HINFO и TXT не используют. Ничего лишнего хакеру не должно быть доступно, тем более, не стоит вводить информацию о компьютере и его ОС. Записи HINFO и TXT чисто информационные и не не- сут в себе никаких полезных данных, способных повлиять на работу сервера. Теперь вернемся к файлу sitename.zone и рассмотрим его содержимое. В первой строке (тип SOA ) идет описание зоны. Сначала указывается имя DNS-сервера ( ns.sitename.com ) и человека, ответственного за запись ( root@sitename.com ). Заметьте , что @ в адресе E-mail заменено точкой, поскольку символ @ имеет особый смысл. В скобках перечислены параметры, которые для удобства расположены каждый в своей строке. Первым идет серийный номер. После каждой корректировки увеличивайте это значение на 1 или записывайте туда дату последнего редактирования. По этому значению другие серверы будут узнавать , было ли изменение записи. Следующий параметр refresh — частота, с которой другие серверы должны обновлять свою информацию. В случае ошибки сервер должен повторить Глава 11 354 попытку через время, указанное в третьем параметре ( retry ). Последний па- раметр ( ttl ) устанавливает минимальное время жизни записи на кэширую- щих серверах, то есть определяет, когда информация о зоне на кэширующем сервере будет считаться недействительной. По этим параметрам остальные DNS-серверы будут знать, как себя вести для обновления информации о зоне, которую контролирует ваш DNS-сервер. Следующая строка имеет тип NS , и таких записей может быть несколько. Сокращение NS в данном случае означает Name Server. Здесь описываются DNS-серверы, которые отвечают за эту зону. Именно через эти серверы все остальные участники будут преобразовывать символьное имя sitename.com в IP-адрес. После этого могут идти записи MX (Mail eXchange). По ним серверы опреде- ляют , куда отправлять почту, которая приходит на домен sitename.com. В нашем примере это сервер mail.sitename.com, а число перед его именем — это приоритет. Если в файле будет несколько записей MX , то они будут ис- пользоваться в соответствии с приоритетом. В Н И МА Н И Е ! В записях типа NS и MX в конце адреса обязательно должна быть точка ! И наконец, в конце идут строки, определяющие преобразования. Они выгля- дят следующим образом: имя A адрес В нашем примере это две строки: ns A 190.12.10.1 mail A 190.12.10.2 Это значит, что имени ns.servername.com соответствует IP-адрес 190.12.10.1, а имени mail.servername.com — 190.12.10.2. 11.6. Обратная зона Теперь рассмотрим файл описания обратного преобразования IP-адреса в имя. 10.12.190.in-addr.arpa.zone может иметь примерно следующий вид: @ IN SOA ns.sitename.com root.sitename.com ( 1 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire DNS- сервер 355 86400 ; ttk ) IN NS localhost. 1 PTR servername.com. 2 PTR mail.servername.com. Б óльшая часть этого файла нам уже знакома. Самое интересное хранится в последних двух строках. Здесь находится связка IP-адресов и имен серве- ров . Не забываем, что файл отвечает за сеть с адресами 190.12.10.*. Звездоч- ка заменяется на число, стоящее в первой колонке, а имя, соответствующее этому адресу, указано в последнем столбце. По этому файлу мы видим сле- дующие соотношения: 190.12.10.1 = servername.com. 190.12.10.2 = mail.servername.com. Еще раз напоминаю, что точка в конце символьного адреса обязательна. Для получения дополнительной информации по DNS рекомендую прочитать документы RFC 1035, RFC 1712, RFC 1706. 11.7. Безопасность DNS Если посмотреть на задачи, которые решает служба, то кажется, что ничего страшного в ней нет, и хакер не сможет ничего сделать. Как бы не так. Были случаи , когда DNS-серверы выводили из строя. Тогда обращение по именам становилось невозможным, а значит, сетевые программы переставали рабо- тать . Пользователи не привыкли использовать IP-адреса, поэтому падение DNS для них смертельно. Помимо вывода из строя сервера, хакер может узнать многое о структуре се- ти , используя DNS. Чтобы этого не произошло, желательно использовать два DNS-сервера: общедоступный , содержащий строки, необходимые для работы удален- ных пользователей с общими ресурсами; локальный , видимый только пользователям вашей сети и содержащий все необходимые для их работы записи. На локальном сервере можно так настроить сетевой экран, чтобы он воспри- нимал только локальный трафик и игнорировал любые попытки обращения Глава 11 356 из всемирной сети. В этом случае злоумышленнику будет проблематично не только посмотреть базу данных DNS, но и нарушить работу сервера. Таким образом , все локальные пользователи будут лучше защищены от нарушения работы DNS и смогут спать спокойным сном под охраной сетевого экрана. Хотя спать на рабочем месте и нехорошо. Для каждого первичного можно завести по одному вторичному серверу. Это позволит распределить нагрузку между ними и уменьшить время отклика и, конечно же, повысить отказоустойчивость. При выходе из строя одного из серверов второй возьмет на себя его функции и не позволит сети остаться без удобной возможности адресации к компьютерам по имени. Использование парных серверов позволяет повысить производительность и безопасность. Сервисы DNS под Linux не требовательны к оборудованию. В моей сети работает четыре сервера на базе Red Hat Linux в текстовом ре- жиме на компьютерах Pentium с частотой от 400 МГц до 700 МГц. Когда-то это были офисные машины, но их мощности перестало хватать, и я превра- тил старое железо в DNS-серверы. Для выполнения этой задачи такой древ- ней техники больше, чем достаточно, и хватит на ближайшие годы. Таким образом , старому компьютеру можно дать новую жизнь, причем достаточно долгую , а, главное, для компании такое решение окажется приемлемым по цене Однако технология создания вторичных серверов опасна. С помощью утили- ты host хакер может добыть полную информацию о содержимом базы дан- ных основного сервера, как это делают вторичные серверы для обновления своей базы. Для получения базы взломщик может выполнить следующую команду: host –l server.com ns1.server.com В ответ на такой запрос хакер получит из базы данных все записи о сервере server.com. Чтобы предотвратить это, необходимо явно прописать адреса вторичных серверов в файле named.conf. Для этого в разделе options{...} добавляем строку: allow-transfer {192.168.1.1;} Такого рода ограничение можно поместить и в описании отдельных зон, но лучше сделать это один раз в глобальных опциях. Если у вас нет вторичных серверов , то запретите перенос данных в эту зону следующей строкой: allow-transfer {none;} Серверы DNS могут быть подвержены атаке DoS. В ноябре 2002 года был произведен один из самых громких налетов на Интернет такого типа. Атака шла сразу на несколько корневых серверов. Если бы работу DNS выполнял DNS- сервер 357 только один сервер, то через некоторое время после начала штурма Интернет стал бы недоступным. Сеть осталась работоспособной благодаря следующим факторам : избыточности серверов, которые дублируют записи; наличию кэширующих серверов; установке прокси-серверов, которые также умеют кэшировать записи DNS. В остальном защита DNS идентична защите любого другого сервиса и ОС Linux. Как я уже говорил, лучший сервер — это тот, который выполняет уз- кую задачу. В нем меньше открытых портов и запущенных сервисов, поэтому его труднее взломать. Единственная сложность — большое количество сер- веров усложняет процесс обновления ОС. В Linux тоже бывают ошибки, и их надо исправлять. Под эту процедуру должны попасть все компьютеры, в том числе и серверы DNS. |