DNS

Настройка клиента DNS

Настройка клиента DNS чрезвычайно проста - следует лишь указать верные значения в /etc/nsswitch.conf и /etc/resolv.conf. В последнем файле надо указывать IP-адрес, а не имя сервера имен, ибо нельзя обратиться к серверу имен по имени - ведь это он должен преобразовывать имена в IP-адреса.

Вот выдержка из файла /etc/nsswitch.conf:

#
# /etc/nsswitch.dns:
#
# An example file that could be copied over to 
# /etc/nsswitch.conf; it uses
# DNS for hosts lookups, otherwise it does not use any 
# other naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of 
# "inet" transports.
passwd: 		files
group: 			files
# You must also set up the /etc/resolv.conf file for 
# DNS name server lookup. See resolv.conf(4).
hosts: 			files dns
ipnodes: 		files
networks: 		files
protocols:		files

Файл resolv.conf при этом выглядит так:

domain eu.spb.ru
nameserver 192.168.5.63
search eu.spb.ru

Настройка сервера DNS

Программа, которая является сервером имен и реализует службу DNS в Solaris, называется in.named (/usr/sbin/in.named). С системой Solaris 9 поставляется пакет BIND версии 8.2.4, в который входит эта программа.

Конфигурационный файл этой программы называется /etc/named.conf. Сервер имен всегда имеет рабочий каталог, где он хранит базу данных информации о доменах.

Этот каталог указывается в инструкции directory в файле конфигурации named.conf, и довольно часто администраторы выбирают в качестве такого каталога /var/named/.

В файле /etc/named.conf кроме имени рабочего каталога указываются все домены, за которые отвечает данный сервер имен, и названия файлов с описаниями этих доменов ; каждому домену соответствует свой файл описания. Один сервер имен может хранить информацию о нескольких доменах.

Правила регистрации доменов требуют, чтобы за каждый домен отвечали, как минимум, два сервера имен в разных IP-сетях; это правило ввели для страховки на случай непредвиденного отключения маршрутизации к одной из сетей.

Прежде чем начать подробное изучение файлов данных и файла конфигурации сервера имен, сделаем важное замечание: во всех этих файлах в Solaris 9 поставляемый с системой in.named ожидал в качестве разделителей полей знаки табуляции, а не пробелы! Если сервер имен при загрузке сообщает, что не смог найти информацию в файле конфигурации или файлах данных, следует:

1. Уточнить, действительно ли вы строго следовали синтаксису файлов. Наиболее распространенными ошибками являются: отсутствие точки с запятой после инструкции в named.conf, отсутствие точки с запятой перед фигурной скобкой в named.conf, использование не тех скобок (круглых в named.conf или фигурных при описании домена в файле данных домена в записи SOA), непарные скобки (часто появляются в результате редактирования ранее созданного файла);
2. Проверить, не являются ли символы-разделители полей в записях в файлах чем-либо, кроме табуляции (такое может возникнуть при переносе файлов откуда-либо методом cut-and-paste). Если не уверены в том, что там верные символы, лучше заменить их на табуляцию.

Рассмотрим файл /etc/named.conf в нашей системе. Положим, наш сервер имен обслуживает два домена: klava.net и macro.ru, причем для последнего домена наш сервер будет выполнять роль вторичного сервера имен.

options {
// это комментарий, раз строка начинается с //
		directory "/var/named";
};
// дальше идет описание зон.
// эти - корневая и обратная локальная - обязательны 
zone "." {
		type hint;
		file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
		type master;
		file "127.0.0";
};
// дальше - описания зон, за которые мы отвечаем
zone "klava.net" {
		type master;
			file "klava.net";
};
// а это - те зоны, для которых наш сервер - вторичный
zone "macro.ru" {
		type slave;
		file "sec/macro.ru";
		masters {
			194.220.38.65;
		};
};

Файл описания корневого домена named.root (фактически, список серверов имен корневого домена ) может быть уже установлен в системе. Если это не так, то его можно получить из самого надежного источника - по адресу ftp://ftp.rs.internic.net/domain/.

Каталог, в котором будут храниться файлы описаний доменов, для которых наш сервер имен является вторичным, должен быть доступен демону in.named для записи. Обычно это каталог /var/named/sec.

Файл описания домена состоит из записей, по одной на строку, называемых записями о ресурсах (RR - resource records). Каждый из ресурсов имеет класс и тип. В сети Интернет используется только класс IN, но DNS позволяет описывать ресурсы и других классов. Мы не будем рассматривать никакие классы, кроме IN. Типы ресурса бывают такими:

• A - указание адреса компьютера с определенным именем (для поиска адреса по имени);
• PTR - указание имени компьютера с определенным адресом (для поиска имени по адресу);
• MX - указание почтового сервера для ресурса ( домена или компьютера);
• CNAME - псевдоним другого ресурса;
• HINFO - текстовое описание ресурса;
• SOA (starting of authority) - служебная информация о домене в целом.
• NS - указание имени сервера имен для домена.

Каждая запись имеет определенный формат, а именно:

имя ресурса	класс		тип	информация

Изучим файлы описания доменов, на которые ссылались инструкции из файла /etc/named.conf:

klava.net:
$TTL	3600
@	IN	SOA	sunny.eu.spb.ru. hostmaster.sunny.eu.spb.ru. (
				2004060101
				3600
				1200
				3600000
				3600 )
	IN	NS		sunny.eu.spb.ru.
	IN	MX	5	mail.eu.spb.ru.
	IN	MX	10	sunny.eu.spb.ru.
mail	IN	A	194.221.15.1
127.0.0:
$TTL	3600
@	IN	SOA	sunny.eu.spb.ru.	hostmaster.sunny.eu.spb.ru. (
						2004060100
						3600
						1200
						3600000
						3600 )
	IN	NS	sunny.eu.spb.ru.
1	IN	PTR	localhost.

Тип SOA - это единственный тип, который предполагает многострочную запись. В записи SOA указывается имя домена (символ @ - это макроопределение, вместо которого подставляется имя домена из файла named.conf), полное имя авторитетного name-сервера домена, адрес персоны, ответственной за домен, времена и тайм-ауты обновления сведений о домене:

• sunny.eu.spb.ru. - это имя авторитетного сервера имен. Авторитетным называется такой сервер имен, ответы которого не подвергаются сомнению. Дело в том, что на запрос о домене может ответить не только сервер имен, отвечающий за этот домен, но и любой другой сервер имен, если он получил эту информацию по запросу. Авторитетный ответ (autoritative answer) может быть получен только с сервера имен, непосредственно отвечающего за интересующий нас домен ;
• hostmaster.sunny.eu.spb.ru. - это адрес e-mail персоны, ответственной за домен ; так как символ @ уже используется в описании домена в другом значении, то здесь он заменен на точку; когда вы будете писать письма ответственному лицу, делайте обратную замену и пишите по адресу hostmaster@sunny.eu.spb.ru.

Обратите внимание на то, что в конце адреса и в конце имени сервера стоит знак "точка" (.) - это для того, чтобы явно указать, что мы имеем дело с полностью определенным доменным именем. Если точку в конце имени не поставить, то после написанного в файле имени будет подставлено имя домена, например, если написать вместо " sunny.eu.spb.ru." то же самое, но без точки - " sunny.eu.spb.ru ", фактически сервер имен поймет это как sunny.eu.spb.ru.klava.net. (если мы говорим об описании домена klava.net ).

После открывающей круглой скобки следует указывать серийный номер версии файла данных домена. Этот номер необходимо изменять каждый раз, когда меняется хоть что-то в описании домена. Если забыть об этом, информация на вторичных серверах имен не обновится.

Серийный номер удобно указывать в формате YYYYMMDDVV, где YYYY - год, MM - месяц, DD - число месяца, VV - версия описания домена за этот день. Как видите, этот стандартный формат ограничивает нас в количестве изменений за день - не более ста. Постарайтесь унять торопливость и вносите изменения, только когда это действительно понадобится, а не раз в пять минут, пожалуйста!

Числа на следующих строках обозначают, соответственно, в секундах:

• 3600 - период опроса главного сервера имен вторичными серверами;
• 1200 - период повторных попыток опроса главного сервера имен вторичными серверами в случае неудачи при первой попытке опроса;
• 3600000 - время устаревания информации на вторичном сервере (т.е. время, через которое вторичный сервер должен считать, что информация потеряла актуальность, и, если не удается получить обновление с главного сервера, перестать отвечать на запросы о домене );
• 3600 - время жизни негативного ответа (т.е. ответа "нет такого компьютера у нас в домене! "). Это время, в течение которого сервер, запросивший информацию от нашего сервера, не будет посылать вторичный запрос, если на первый запрос пришел отрицательный ответ.

Инструкция $TTL в начале файла указывает, что серверы, получающие от нас ответы на свои вопросы, должны кэшировать эти ответы на время TTL (в секундах).

Записи типа NS содержат имена серверов имен домена, причем здесь не делается различия между главными и вторичными серверами имен, порядок следования записей в файле домена сам по себе ничего не означает.

Записи MX описывают правила маршрутизации почты. Каждая запись указывает на один из почтовых серверов, принимающих почту для данного домена (или компьютера):

IN	MX	5	mail.eu.spb.ru.
	IN	MX	10	sunny.eu.spb.ru.

В приведенном выше примере почта для домена klava.net принимается одним из двух почтовых серверов - mail.eu.spb.ru или sunny.eu.spb.ru. Число, следующее за ключевым словом MX в записях о маршрутизации почты, называется показателем предпочтительности (preference). Это число показывает, насколько предпочтительно посылать почту на указанный почтовый сервер по сравнению с другими почтовыми серверами. Если для домена или компьютера указаны несколько записей MX с различными показателями предпочтительности, то почта направляется на первый доступный почтовый сервер с минимальным значением показателя предпочтительности.

Алгоритм отправки почты любым почтовым сервером таков:

1. Почтовый сервер отправителя запрашивает свой сервер имен (тот, что указан в /etc/resolv.conf ), куда надо отправить письмо для указанного в заголовке письма адресата.
2. Сервер имен выдает ему список записей MX для адресата.
3. Почтовый сервер выбирает запись с наименьшим значением показателя предпочтительности и пытается отправить почту указанному в этой записи почтовому серверу.
4. Если это не удается, выбирается следующая запись с минимальным (из оставшихся) показателем предпочтительности и делается попытка отправить почту через указанный в ней почтовый сервер.

Попытки отправки почты повторяются до тех пор, пока почтовое сообщение не будет успешно отправлено либо время, прошедшее с начала первой попытки, не превысит установленный тайм-аут. В последнем случае отправитель получит уведомление о невозможности доставить письмо. По умолчанию большинство почтовых серверов пытаются доставить письмо в течение 5 суток.

Все временно неотправленные письма накапливаются в очереди сообщений, и почтовый сервер регулярно обрабатывает очередь, вновь и вновь пытаясь отправить письма согласно вышеописанному алгоритму.