Каждый компьютер, подключенный к сети, должен иметь свой адрес, чтобы его легко можно было найти и обмениваться с ним данными. Это как телефонные аппараты. Чтобы кому-нибудь позвонить, нужно знать его номер телефона, иначе коммутатор не сможет понять, с кем вас соединить.
Когда вы хотите получить Web-страничку с сервера, то необходимо знать его адрес. В запросе нужно указать свои координаты, чтобы сервер знал, куда вернуть требуемую страничку. Здесь просматривается аналогия с почтой. Вы отправляете письмо на определенный адрес, и если хотите, чтобы вам ответили, то должны указать обратный адрес.
В эпоху зарождения сетей компьютеров в ней было мало, поэтому для адресации был выбран самый простой вариант — числа. С увеличением количества компьютеров сетевая общественность стала осознавать, что помнить больше 20 адресов невозможно, поэтому было принято решение найти какой- либо способ, упрощающий запоминание.
Изменять принцип нумерации поздно, да и выбранная IP-система очень удобна для обработки на программном уровне компьютерами и сетевыми устройствами. Немного поколдовав, умные люди придумали создать централизованную базу данных, устанавливающую соответствие IP-адресов и символьных имен. Таким образом, пользователь оперирует именами узлов, а программа уже по базе DNS находит нужный IP-адрес и по нему соединяется с компьютером/сервером.
Этот метод очень сильно упростил задачу. Раньше, чтобы найти сервер, нужно было четко знать его IP-адрес. Теперь в простой ситуации можно обойтись даже без поисковых систем типа yahoo или google. Например, если нужен сайт корпорации Microsoft, то можно попробовать набрать в браузере адрес www.microsoft.com. Таким образом, Web-серверы фирм можно найти просто по их имени, и не надо запоминать лишнюю информацию.
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.
Рис. 11.1. Иерархия доменов
Допустим, что нужно найти IP-адрес сервера www.cydsoft.com. Имя разбирается справа налево. Сначала направляется запрос к корневому DNS-серверу, который должен указать, кто обслуживает домен com. Затем на найденном сервере по запросу осуществляется поиск домена с именем cydsoft. Если такой найден, то мы получим адрес DNS-сервера, который обслуживает cydsoft.com. И уже ему направляется запрос на получение адреса домена www.cydsoft.com. Результатом будет IP-адрес сервера/компьютера, которому присвоено имя www.cydsoft.com.
Все эти действия происходят прозрачно для конечного пользователя, и когда вы набираете в браузере адрес, то никогда не увидите всех этих тонкостей. О том, что идет поиск 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 указывают на текущую машину. Это значит, что если нужно выполнить 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-серверу. Что это нам дает? А то, что можно увеличить скорость доступа к основным серверам. Допустим, что вы каждый день посещаете сайт http://www.redhat.com/, при этом каждый раз происходит запрос к DNS-серверу, что может служить задержкой в пару секунд перед началом загрузки страницы. Чтобы ускорить этот процесс, можно вручную прописать в файл /etc/hosts следующую запись:
209.132.177.50 www.redhat.com
Внимание!
Адрес 209.132.177.50 действительно соответствует сайту www.redhat.com на момент написания книги, но может измениться.
Если сайт по каким-либо причинам перестал загружаться, то необходимо удалить соответствующую запись из файла hosts, и с помощью команды ping redhat.com проверить связь с сервером, а заодно узнать его адрес. В ответ на эту директиву на экране обязательно отображается реальный IP-адрес, с которым происходит обмен эхо-сообщениями. Благо IP-адреса у большинства сайтов изменяются редко, и один раз добавив такую запись в локальный файл /etc/hosts, можно сэкономить достаточно много времени и нервов в случае проблем с DNS-сервером, потому что запроса к нему не будет.
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.2 вы можете увидеть запущенное приложение для настройки DNS-сервиса. В центре показано окно, которое появляется по нажатию кнопки Добавить. Как видите, достаточно только выбрать тип зоны и ввести имя домена, и все готово.
Рис. 11.2. Окно для настройки DNS-сервиса
Несмотря на наличие простой графической программы, мы рассмотрим работу DNS на примере конфигурационных файлов, которые могут использоваться сервисом. Их прямое редактирование позволит сделать более тонкую настройку, и вы лучше будете понимать процесс работы DNS.
Настройка DNS-сервиса начинается с файла /etc/named.conf. Пример его содержимого приведен в листинге 11.1.
Листинг 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 (файл, в котором содержится описание).
Самая первая зона в нашем примере описана следующим образом:
zone "." {
type hint;
file "named.ca";
};
Что это за зона в виде точки? Вспомните теорию DNS, которую мы рассматривали в начале главы. В базе данных DNS так обозначается корень. Получается, что раздел описывает корневую зону. Тип зоны hint, т.е. наш сервер, будет всего лишь хранить ссылки на DNS-серверы. Так как это корневая зона, то и ссылки будут на корневые серверы.
В параметре file указывается имя файла, содержащего все ссылки на корневые серверы. В системе этого файла может и не быть, потому что информация в нем может изменяться, и лучше всего получить последнюю версию с сервера internic.net. Для этого выполните команду:
dig @rs.internic.net . ns > named.ca
Перейдем к следующему разделу:
zone "sitename.com" {
type master;
file "sitename.zone";
};
Здесь описывается зона sitename.com. Тип записи master, значит ваш DNS-сервер будет главным, а все остальные будут только сверяться с ним и кэшировать информацию. Сведения об этой зоне будут храниться в файле sitename.zone рабочей директории. В нашем случае это /var/named.
Следующая зона описывает обратное преобразование IP-адресов 190.12.10.* в имена:
zone "10.12.190.in-addr.arpa" {
type master;
file "10.12.190.in-addr.arpa.zone";
};
Тип записи — снова master, и в последней строке указан файл, где будет находиться описание зоны.
11.5. Файлы описания зон
Теперь посмотрим, что у нас находится в директории /var/named. Судя по файлу конфигурации /etc/named.conf, у нас здесь должно быть три файла:
□ named.ca — хранит ссылки на корневые серверы. Этот файл просто забирается с сервера internic.net, поэтому его редактировать не стоит, и даже не будем на нем останавливаться;
□ sitename.zone — отвечает за преобразование имени sitename.com в 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
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, Каноническое имя) — синоним для реального доменного имени, которое указано в записи типа А;
□ PTR (Pointer, Указатель) — отображение доменного имени по его IP-адресу;
□ TXT (Text, Текст) — дополнительная информация, которая может содержать любое описание;
□ RP (Responsible Person, Ответственное лицо) — E-mail-адрес ответственного за работу человека;
□ HINFO (Host Information) — информация о компьютере, такая как описание ОС и установленного оборудования.
В целях безопасности записи HINFO и TXT не используют. Ничего лишнего хакеру не должно быть доступно, тем более не стоит вводить информацию о компьютере и его ОС. Записи HINFO и TXT чисто информационные и не несут в себе никаких полезных данных, способных повлиять на работу сервера.
Теперь вернемся к файлу sitename.zone и рассмотрим его содержимое. В первой строке (тип SOA) идет описание зоны. Сначала указывается имя DNS-сервера (ns.sitename.com) и человека, ответственного за запись ([email protected]). В скобках перечислены параметры, которые для удобства расположены каждый в своей строке. Первым идет номер записи. После каждой корректировки увеличивайте это значение на 1 или записывайте туда дату последнего редактирования. По этому значению другие серверы будут узнавать, было ли изменение записи.
Следующий параметр refresh — частота, с которой другие серверы должны обновлять свою информацию. В случае ошибки сервер должен повторить попытку через время, указанное в третьем параметре (retry).
Последний параметр (ttl) устанавливает минимальное время жизни записи на кэширующих серверах, т.е. определяет, когда информация о зоне на кэширующем сервере будет считаться недействительной.
По этим параметрам остальные DNS-серверы будут знать, как себя вести для обновления информации о зоне, которую контролирует ваш DNS-сервер.
Следующая строка имеет тип NS, и таких записей может быть несколько. Сокращение NS в данном случае означает Name Server. Здесь описываются DNS-серверы, которые отвечают за эту зону. Именно через эти серверы все остальные участники будут преобразовывать символьное имя sitename.com в IP-адрес.
После этого могут идти записи MX (Mail eXchange). По ним серверы определяют, куда отправлять почту, которая приходит на домен sitename.com. В нашем примере это сервер mail.sitename.com, а число перед его именем — это приоритет. Если в файле будет несколько записей MX, то они будут использоваться в соответствии с приоритетом.
Внимание!
В записях типа NS и MX в конце адреса обязательно должна быть точка!
И наконец, строки преобразования. Они выглядят следующим образом:
имя А адрес
В нашем примере две строки:
ns A 190.12.10.1
mail A 190.12.10.2
Это значит, что имена ns.servername.com и mail.servername.com соответствуют IP-адресу 190.12.10.1.
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
86400 ; ttk
)
IN NS localhost.
1 PTR servername.com.
2 PTRmail.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-сервера:
1. Общедоступный, содержащий необходимые строки для работы удаленных пользователей с общими ресурсами.
2. Локальный, видимый только пользователям вашей сети и содержащий все необходимые записи для их работы.
На локальном сервере можно так настроить сетевой экран, чтобы он воспринимал только внутренний трафик и игнорировал любые попытки обращения из всемирной сети. В этом случае злоумышленнику будет проблематично не только посмотреть базу данных DNS, но и нарушить работу сервера. Таким образом, все локальные пользователи будут лучше защищены от нарушения работы DNS и могут спать спокойным сном, пока их охраняет сетевой экран.
Для каждого первичного можно завести по одному вторичному серверу. Это позволит распределить нагрузку между ними и уменьшить время отклика и, конечно же, повысить отказоустойчивость. При выходе из строя одного из серверов второй возьмет на себя его функции и не позволит сети остаться без удобной возможности адресации к компьютерам по имени.
Использование парных серверов позволяет повысить производительность и безопасность. Сервисы DNS под Linux не очень требовательны к оборудованию, В моей сети работает четыре сервера на базе Red Hat Linux в текстовом режиме на компьютерах Pentium с частотой от 400 до 700 МГц. Когда-то это были офисные машины, но их мощности перестало хватать, и я превратил старое железо в DNS-серверы. Для выполнения этой задачи такой древней техники более чем достаточно и хватит на ближайшие годы. Таким образом, старому компьютеру можно дать новую жизнь, и довольно долгую, а главное, что для компании такое решение окажется приемлемым по цене.
Но технология создания вторичных серверов опасна. С помощью команды host хакер может добыть полную информацию о содержимом базы данных основного сервера, как это делают вторичные серверы для обновления своей базы.
Для получения базы взломщик может выполнить следующую директиву:
host -l server.com nsl.server.com
В ответ на это хакер получит из базы данных все записи о сервере server.com, Чтобы предотвратить это, необходимо явно прописать адреса вторичных серверов в файле named.conf. Для этого в разделе options{...} добавляем строку:
allow-transfer {192.168.1.1;}
Такого рода ограничение можно поместить и в описании отдельных зон, но лучше сделать это один раз в глобальных опциях. Если у вас нет вторичных серверов, то запретите перенос данных в эту зону следующей строкой:
allow-transfer {none;}
Серверы DNS могут быть подвержены атаке DoS. В ноябре 2002 года был произведен один из самых громких налетов на Интернет такого типа. Атака шла сразу на несколько корневых серверов. Если бы работу DNS выполнял только один сервер, то через некоторое время после начала штурма Интернет стал бы недоступным. Сеть осталась работоспособной благодаря следующим факторам:
□ избыточности серверов, которые дублируют записи;
□ наличию кэширующих серверов;
□ установке прокси-серверов, которые также умеют кэшировать DNS-записи.
В остальном защита DNS и любых других сервисов и ОС Linux идентичны. Как я уже говорил, лучший сервер — это тот, который выполняет узкую задачу. В нем меньше открытых портов и запущенных сервисов, поэтому его труднее взломать. Единственная сложность — большое количество серверов усложняет процесс обновления ОС. В Linux тоже бывают ошибки, и их надо исправлять, поэтому под эту процедуру попадают все серверы, в том числе и DNS.