«DNS и BIND»
4. Установка BIND
Запуск первичного DNS-сервера
Итак, создав файлы данных для зоны, мы готовы к запуску пары DNS-серверов. Речь идет об основном контрольном сервере имен и вторичном сервере имен. Однако прежде чем запускать DNS-сервер, следует убедиться, что запущен демон syslog. Если DNS-сервер при чтении файла настройки или зональных данных находит ошибку, информация об этой ошибке заносится в log-файл с помощью демона syslog. Если ошибка критическая, DNS-сервер прекращает работу. Если вы выполнили команды BIND 9 named-checkconf и named-checkzone, то вы готовы к работе, но на всякий случай все ж е загляните в журнал syslog.
Запуск DNS-сервера
Мы предполагаем, что к данному моменту на машине уже установлен DNS-сервер BIND и программа nslookup. Сверьтесь с руководством по named в поисках каталога, который содержит исполняемый файл сервера, и убедитесь, что этот исполняемый файл присутствует в системе. В системах BSD DNS-сервер начинал свое существование в каталоге /etc, но вполне мог переместиться в /usr/sbin. Также named можно поискать в /usr/etc/in.named и /usr/sbin/in.named. Последующие описания подразумевают, что файл расположен в каталоге /usr/sbin.
Чтобы запустить сервер, следует получить полномочия суперпользователя (root). Сервер имен принимает запросы через привилегированный порт, а для этого требуются права пользователя root. На первый раз запустите DNS-сервер из командной строки, чтобы убедиться в его корректной работе. Позже мы объясним, как автоматически запускать сервер при загрузке системы.
Следующая команда запускает DNS-сервер. Мы выполнили ее на узле toystory.movie.edu:
# /usr/sbin/named
Такая команда подразумевает, что файлом настройки является /etc/named. conf. Файл настройки может находиться в другом месте, но в этом случае следует указать DNS-серверу, где именно, используя ключ - c :
# /usr/sbin/named -c conf-file
Ошибки в log-файле syslog
Первое, что следует сделать после запуска DNS-сервера, - заглянуть вlog-файл демона syslog в поисках сообщений об ошибках. Те, кто незнаком с демоном syslog, могут взглянуть на страницы руководства по файлу syslog.conf и ознакомиться с описанием файла настройки syslog либо изучить документацию по программе syslogd (которая и содержит описание демона syslog). Сервер имен заносит сообщения в log-файл как daemon (демон) под именем named. Узнать, в какой файл записываются сообщения демона syslog, можно, найдя слово daemon вфайле /etc/syslog.conf:
% grep daemon /etc/syslog.conf
*.err;kern.debug;daemon,auth.notice /var/adm/messages
На этом узле syslog-сообщения от DNS-сервера заносятся в log-файл, хранимый в файле /var/adm/messages, и при этом syslog пропускает только сообщения, которые имеют приоритет LOG_NOTICE или более высокий. Некоторые полезные сообщения имеют приоритет LOG_INFO, и вы можете захотеть их прочитать. Следует ли изменять этот уровень, читатели смогут решить, прочтя главу 7, в которой мы рассмотрим сообщения syslog более подробно.
При запуске DNS-сервера в log-файл заносится стартовое сообщение:
% grep named /var/adm/messages
Jan 10 20:48:32 toystory named[3221]: starting BIND 9.3.2 -c named.boot
Стартовое сообщение не является сообщением об ошибке, но за ним могут следовать другие сообщения, обладающие этим свойством. Наиболее часто встречаются синтаксические ошибки в файлах данных зоны и файле настройки. К примеру, если мы забудем указать тип записи в адресной записи:
shrek IN 192.249.249.2
сервер отреагирует следующим syslog-сообщением:
Jan 10 20:48:32 toystory named[3221]: db.movie.edu:24: Unknown RR type:
192.249.249.2
Если сделать орфографическую ошибку в слове «zone» в файле /etc/ named.conf:
zne "movie.edu" in {
будет получено следующее сообщение об ошибке:
Mar 22 20:14:21 toystory named[1477]: /etc/named.conf:10:
unknown option 'zne'
Если BIND находит имя, которое не соответствует стандарту, установленному документом RFC 952, в журнал syslog попадет такое сообщение:
Jul 24 20:56:26 toystory named[1496]: db.movie.edu:33: a_b.movie.edu: bad
owner name
Если речь идет о синтаксической ошибке, следует проверить строки, которые упоминаются в сообщениях syslog, и попытаться понять, в чем проблема. Читатели уже представляют себе, как должны выглядеть файлы данных зоны; этого представления должно быть достаточно, чтобы разобраться с самыми простыми ошибками. В сложных случаях им придется обращаться к приложению A «Формат сообщений DNS и RR-записей», а значит, к кровавым подробностям синтаксиса всех RR-записей. Если синтаксическая ошибка поддается исправлению, следует исправить ее, после чего перезагрузить сервер командой ndc (BIND 8) или rndc (BIND 9):
# ndc reload
Эта команда предписывает серверу прочитать файлы данных повторно.[1] Использование ndc и rndc для управления DNS-сервером более подробно описано в главе 7.
Тестирование системы с помощью nslookup
В случае корректного создания локальных зон и действующего подключения к сети Интернет не должно возникать никаких сложностей при выполнении запросов по локальному или удаленному доменному имени. Сейчас мы произведем несколько операций поиска с помощью nslookup. В этой книге программе nslookup посвящена целая глава 12, но мы достаточно подробно рассмотрим ее здесь, чтобы произвести базовое тестирование DNS-сервера.
Установка локального доменного имени
Прежде чем начать работу с nslookup, следует установить локальное доменное имя узла. После этого можно будет производить поиск по имени carrie без необходимости полностью произносить carrie.movie. edu - доменное имя movie.edu будет добавляться системой автоматически.
Существуют два способа установки локального доменного имени: с помощью программы hostname(1) либо указанием в файле /etc/resolv. conf. Некоторые утверждают, что на практике в большинстве случаев применяется указание в файле /etc/resolv.conf. Используйте любой из способов. В этой книге мы предполагаем, что локальное доменное имя получается посредством hostname(1).
Создайте файл /etc/resolv.conf и добавьте в него следующую строку, начав ее с первой позиции строки (вместо movie.edu используйте локальное доменное имя):
domain movie.edu
Либо с помощью hostname(1) задайте доменное имя. Для узла toystory мы использовали hostname(1) и доменное имя toystory.movie.edu. Точку к имени добавлять не следует.
Поиск для локального доменного имени
nslookup можно использовать для поиска RR-записей любого типа через любой DNS-сервер. По умолчанию происходит поиск адресных (A) записей, а запросы посылаются первому из DNS-серверов, определенных в файле resolv.conf. (Если имя DNS-сервера не указано в resolv. conf, DNS-клиент посылает запросы локальному DNS-серверу.) Чтобы найти адрес узла с помощью nslookup, следует выполнить nslookup с единственным аргументом - доменным именем узла. Поиск для локального доменного имени должен вернуть результаты практически мгновенно.
Мы выполнили nslookup для узла carrie:
% nslookup carrie
Server: toystory.movie.edu
Address: 192.249.249.3
Name: carrie.movie.edu
Address: 192.253.253.4
Если поиск для локального доменного имени работает, локальный DNS-сервер был настроен правильно для зоны прямого отображения. Если поиск возвращает ошибку, пользователь получает сообщение, вроде этого:
*** toystory.movie.edu can't find carrie: Non-existent domain
Такое сообщение означает, что узел carrie не входит в зону (проверьте файл данных зоны), либо не было установлено локальное доменное имя (hostname(1)), либо присутствовали иные ошибки в работе DNS-сервера (хотя их следовало отловить при проверке сообщений syslog).
Поиск для локального адреса
Если nslookup в качестве аргумента получает адрес, то выполняется PTR-запрос вместо адресного. Мы выполнили nslookup для адреса узла carrie:
% nslookup 192.253.253.4
Server: toystory.movie.edu
Address: 192.249.249.3
Name: carrie.movie.edu
Address: 192.253.253.4
Если поиск по адресу работает, локальный DNS-сервер был настроен правильно для зоны in-addr.arpa (зоны обратного отображения). Если поиск не сработает, будет отображено сообщение об ошибке, похожее на то, что было бы получено при поиске по доменному имени.
Поиск для внешнего доменного имени
Следующий шаг - попытаться использовать локальный DNS-сервер для поиска по внешнему доменному имени, скажем ftp.uu.net, или имени любой другой системы, которая нам известна и расположена в сети Интернет. Эта команда возвращает результат не столь быстро, как предыдущие. Если nslookup не получает ответ от локального DNS-сервера, пройдет чуть больше минуты, прежде чем работа завершится с соответствующим сообщением.
% nslookup ftp.rs.internic.net.
Server: toystory.movie.edu
Address: 192.249.249.3
Name: ftp.rs.internic.net
Addresses: 198.41.0.6
Если получен положительный результат, можно сделать вывод, что локальному DNS-серверу известны координаты корневых DNS-серверов и способы связи с ними, которые позволяют получать информацию по доменным именам, расположенным во внешних зонах. В случае отрицательного ответа причиной может быть отсутствие файла корневых указателей (соответствующее сообщение syslog будет занесено в log-файл) либо наличие неполадок в сети, которые не позволяют установить связь с DNS-серверами внешней зоны. Имеет смысл повторить попытку для другого доменного имени.
Если уже первые попытки поиска увенчались успехом, можете принимать поздравления! Первичный сервер DNS запущен и функционирует. С этого момента можно начинать настройку вторичного DNS-сервера.
Еще один тест
Но раз уж мы начали тестировать, выполним еще одну проверку. Выясните, делегировали ли DNS-серверы родительской зоны наши зоны только что созданному домену должным образом. Если предки потребовали наличия двух работающих DNS-серверов для делегирования, пропустите этот раздел и переходите к следующему.
Эта проверка состоит из двух шагов. Сначала надо выяснить IP-адрес DNS-сервера родительской зоны. Для этого запросите у своего DNS-сервера NS-записи родительской зоны. Здесь снова придется использовать nslookup, на этот раз с ключом -type=ns, который предписывает программе вернуть записи типа NS.
Вот пример. Предположим, что мы настраиваем зону hp.com, и нам требуется узнать, какие серверы DNS обслуживают родительскую зону com.
% nslookup -type=ns com.
Server: toystory.movie.edu
Address: 192.249.249.3#53
Non-authoritative answer:
com nameserver = i.gtld-servers.net
com nameserver = j.gtld-servers.net
com nameserver = k.gtld-servers.net
com nameserver = l.gtld-servers.net
com nameserver = m.gtld-servers.net
com nameserver = a.gtld-servers.net
com nameserver = b.gtld-servers.net
com nameserver = c.gtld-servers.net
com nameserver = d.gtld-servers.net
com nameserver = e.gtld-servers.net
com nameserver = f.gtld-servers.net
com nameserver = g.gtld-servers.net
com nameserver = h.gtld-servers.net
a.gtld-servers.net internet address = 192.5.6.30
a.gtld-servers.net AAAA IPv6 address = 2001:503:a83e::2:30
b.gtld-servers.net internet address = 192.33.14.30
b.gtld-servers.net AAAA IPv6 address = 2001:503:231d::2:30
c.gtld-servers.net internet address = 192.26.92.30
d.gtld-servers.net internet address = 192.31.80.30
e.gtld-servers.net internet address = 192.12.94.30
f.gtld-servers.net internet address = 192.35.51.30
g.gtld-servers.net internet address = 192.42.93.30
h.gtld-servers.net internet address = 192.54.112.30
i.gtld-servers.net internet address = 192.43.172.30
j.gtld-servers.net internet address = 192.48.79.30
k.gtld-servers.net internet address = 192.52.178.30
l.gtld-servers.net internet address = 192.41.162.3
m.gtld-servers.net internet address = 192.55.83.30
Теперь необходимо запросить у одного из серверов DNS родительской зоны NS-записи. И снова команда nslookup с ключом -type=ns, но на этот раз потребуется добавить еще ключ -norecurse, который предотвратит выполнение рекурсивного поиска. Кроме этого, следует обращаться напрямую к серверу имен родительской зоны, а не к своему серверу имен. (Ваш сервер, естественно, обладает NS-записями искомой зоны, но это не то, что нам нужно проверить.) Чтобы обратиться к серверу DNS родительской зоны, а не к собственному, добавьте имя одного из таких серверов в конец команды nslookup. В следующем примере мы обратились к серверу имен зоны com, b.gtld-servers.net, и запросили NS-записи для hp.com.
% nslookup -type=ns -norecurse hp.com. b.gtld-servers.net.
Server: b.gtld-servers.net
Address: 192.33.14.30#53
Non-authoritative answer:
hp.com nameserver = am1.hp.com
hp.com nameserver = am3.hp.com
hp.com nameserver = ap1.hp.com
hp.com nameserver = eu1.hp.com
hp.com nameserver = eu2.hp.com
hp.com nameserver = eu3.hp.com
am1.hp.com internet address = 15.227.128.
am3.hp.com internet address = 15.243.160.
ap1.hp.com internet address = 15.211.128.
eu1.hp.com internet address = 16.14.64.50
eu2.hp.com internet address = 16.6.64.50
eu3.hp.com internet address = 16.8.64.50
Для hp.com, как и ожидалось, все настроено корректно.
Если ваш сервер имен успешно вернул адрес узла ftp.rs.internic.net и серверы родительского домена, это означает, что он настроен верно, и вы можете работать с сетью Интернет. Если сервер DNS родительской зоны не возвращает NS-записи для вашей зоны, ваша зона не была зарегистрирована в настройках DNS-серверов родительской зоны.
Поначалу это не вызовет особых проблем, поскольку системы в пределах локальных зон могут успешно находить данные для локальных доменных имен и имен, принадлежащих внешним зонам. Вы сможете просматривать веб-страницы и использовать FTP для работы с локальными и удаленными системами. Однако через некоторое время отсутствие такой регистрации станет проблемой. Узлы, не принадлежащие локальным зонам, не смогут находить доменные имена в ваших зонах, так что вы, возможно, не сможете посылать почту друзьям, обитающим во внешних зонах, и совершенно точно не сможете получать их ответы. Чтобы решить эту проблему, следует связаться с администратором родительской зоны и попросить его проверить делегирование ваших зон.
Редактирование загрузочных файлов
Убедившись, что DNS-сервер работает правильно и может использоваться в дальнейшем, следует настроить его автоматическую загрузку и установку доменного имени в загрузочных файлах (или в файле /etc/ resolv.conf). Возможно, поставщик операционной системы уже позаботился о том, чтобы DNS-сервер стартовал при загрузке. Возможно, понадобится раскомментировать соответствующие строки в загрузочных файлах, в других случаях в этих файлах может происходить проверка существования файла /etc/named.conf. Найти строки для автоматического запуска сервера можно с помощью следующей команды:[2]
% grep named /etc/*rc*
% grep named /etc/rc*/S*
Если поиск не принес результатов, добавьте примерно такие строки в соответствующий файл инициализации с учетом того, что они должны выполняться после того, как сетевые интерфейсы будут инициализированы с помощью ifconfig:
if test -x /usr/sbin/named -a -f /etc/named.conf
then
echo "Starting named"
/usr/sbin/named
fi
Возможно, вы захотите запустить DNS-сервер после того, как узлу будет указан роутер по умолчанию или будет запущен демон маршрутизации (routed или gated), в зависимости от того, нужен ли этим службам DNS-сервер или они могут обойтись файлом /etc/hosts.
Узнайте, в каком из загрузочных файлов происходит инициализация имени узла. Измените имя узла (hostname(1)) на доменное имя. Например, мы изменили:
hostname toystory
hostname toystory.movie.edu
[1] В случае сервера имен BIND 9 потребуется использовать rndc, но мы еще не рассказывали о настройке этой программы. Информация об этом содержится в главе 7. А ndc работает практически без настройки.
[2] Для Linux данная команда будет выглядеть так: grep named /etc/rc.d/*/S*. - Примеч. ред.
Добавить комментарий