LXF97:Служба доменных имен - История изменений

Crazy Rebel: /* dnsmasq: не BIND’ом единым... */

2008-10-21T09:38:40Z

dnsmasq: не BIND’ом единым...

← Предыдущая		Версия 09:38, 21 октября 2008
Строка 203:		Строка 203:
	{{Врезка		{{Врезка
	\|Заголовок=Скорая помощь		\|Заголовок=Скорая помощь
-	\|Содержание=Если ваш DHCP-клиент ISC при каждой перезагрузке затирает '''resolv.conf''', раскомментируйте строку «'''prepend	+	\|Содержание=Если ваш DHCP-клиент ISC при каждой перезагрузке затирает '''resolv.conf''', раскомментируйте строку «'''prepend domain-name-servers 127.0.0.1;'''» в '''/etc/dhcp3/dhclient.conf'''. Вместо 127.0.0.1 укажите IP-адрес своего DNS-сервера.
-	domain-name-servers 127.0.0.1;'''» в '''/etc/dhcp3/dhclient.conf'''. Вместо 127.0.0.1 укажите IP-адрес своего DNS-сервера.	+
	\|Ширина=200px}}		\|Ширина=200px}}

Crazy Rebel в 09:37, 21 октября 2008

2008-10-21T09:37:21Z

← Предыдущая		Версия 09:37, 21 октября 2008
Строка 193:		Строка 193:

	Такими настройками мы выделили два «вида» – для наших клиентов (сеть 1.2.3.0/24) и всех остальных. Осталось лишь подготовить различные файлы одних и тех же зон для разных «видов», и задача будет решена. Обратите внимание, что если вы приняли решение использовать «виды», то не должно быть ни одного оператора zone, не входящего в какой-нибудь оператор '''view'''.		Такими настройками мы выделили два «вида» – для наших клиентов (сеть 1.2.3.0/24) и всех остальных. Осталось лишь подготовить различные файлы одних и тех же зон для разных «видов», и задача будет решена. Обратите внимание, что если вы приняли решение использовать «виды», то не должно быть ни одного оператора zone, не входящего в какой-нибудь оператор '''view'''.
		+
		+	===dnsmasq: не BIND’ом единым...===
		+
		+	''BIND'' является одним из самых мощных и настраиваемых DNS-серверов. Однако порой его возможности выглядят излишними, а кого-то могут и испугать...
		+
		+	Конечно, ''BIND'' нельзя назвать ресурсоемким приложением, особенно применительно к современному оборудованию. Да и настройки
		+	не столь обременительны, в чем я, надеюсь, вас убедил. Однако, если единственной задачей, возлагаемой на локальный DNS-сервер, является кэширование запросов пользователей, то для ее решения можно воспользоваться и более специализированным сервисом.
		+
		+	{{Врезка
		+	\|Заголовок=Скорая помощь
		+	\|Содержание=Если ваш DHCP-клиент ISC при каждой перезагрузке затирает '''resolv.conf''', раскомментируйте строку «'''prepend
		+	domain-name-servers 127.0.0.1;'''» в '''/etc/dhcp3/dhclient.conf'''. Вместо 127.0.0.1 укажите IP-адрес своего DNS-сервера.
		+	\|Ширина=200px}}
		+
		+	Одним из таковых является кэширующий DNS-сервер ''dnsmasq'' (по совместительству он может выполнять и роли DHCP-сервера, раздавая машинам локальной сети IP-адреса и прочие сетевые настройки, необходимые для работы, и TFTP-сервера для обеспечения работы бездисковых станций, загружающихся по сети). Его установка выполняется столь же легко, как и BIND – многие дистрибутивы уже включают его в базовой поставке, если нет – почти наверняка вы найдете его в официальном репозитории. Для настройки используется файл '''/etc/dnsmasq.conf''' (в других дистрибутивах место расположения может быть иным). То, что конфигурационный файл содержит свыше 400 строк, не должно вас пугать – большую их часть составляют довольно подробные комментарии, да и значимые строки отвечают преимущественно за работу сервера DHCP. Основные же DNS-параметры сосредоточены
		+	в начале файла.
		+
		+	На что следует обратить внимание в настройках? Во-первых, ''dnsmasq'' руководствуется файлом '''resolv.conf''', определяя, каким DNS-серверам следует перенаправлять запросы, которые не могут быть удовлетворены из кэша. При необходимости вы можете определить другой файл вместо '''/etc/resolv.conf''' в параметре '''resolv-file''' либо запретить его использование, раскомментировав параметр '''no-resolv'''. Параметрами server можно указывать «вышестоящие» DNS-серверы прямо в конфигурационном файле. Причем вы можете даже задавать различные серверы для отдельных доменов:
		+
		+	<code>
		+	no-resolv
		+	server=/provider.ru/1.2.3.4
		+	server=4.3.2.1
		+	</code>
		+
		+	Эти строки предписывают ''dnsmasq'' игнорировать сведения из '''/etc/resolv.conf''' и использовать сервер 1.2.3.4 для разрешения имен домена http://provider.ru, и сервер 4.3.2.1 для всех прочих запросов. Помимо выбора forward-серверов, вы можете указать пользователя и группу, от имени которых будет выполняться ''dnsmasq'', конкретизировать интерфейсы, на которых ''dnsmasq'' будет ожидать запросы от пользователей и т.д.
		+
		+	Еще одна полезная особенность – по умолчанию ''dnsmasq'' при старте читает файл '''/etc/hosts''' и заносит найденную там информацию в свой кэш. Благодаря этому можно обеспечить разрешение локальных имен без необходимости синхронизировать '''/etc/hosts''' на всех машинах локальной сети. Если вам эта функция не нужна, отключите ее опцией '''no-hosts'''.
		+
		+	Помимо редактирования файла '''dnsmasq.conf''', практически все параметры работы можно задать непосредственно в командной строке. Подробности – на man-страницах.
		+
		+	Как видите, собственный DNS-сервер может оказаться весьма полезной (ну, как минимум, интересной) штукой, даже если в вашей
		+	локальной сети всего пара машин, а о собственном домене вы и не помышляете. И настроить его совсем не сложно. Так что дерзайте!
		+
		+	====Другая точка зрения====
		+
		+	DNS работает как бы сам по себе, но если начинаются проблемы, это сказывается самым неожиданным образом на самых различных приложениях: от браузера до сервера электронной почты. Пока за DNS отвечает ваш провайдер, беспокоиться особо не о чем, но раз уж мы взялись сами за настройки этой службы, то нужно быть готовым к различным сюрпризам.
		+
		+	Традиционно для тестирования работы DNS используются утилиты ''nslookup'' и ''dig''. Первая издавна шла в составе пакета ''BIND'', и пользоваться ею очень просто – укажите в качестве аргумента доменное имя, и утилита вернет IP-адрес и сведения о сервере, который использовался для разрешения имени. При необходимости вы можете указать любой DNS-сервер вторым аргументом, которому будет отправлен запрос:
		+
		+	<code>
		+	amsand:~$ nslookup linuxformat.ru ns.mezon.ru
		+	Server: ns.mezon.ru
		+	Address: 83.68.34.21#53
		+	Name: linuxformat.ru
		+	Address: 88.212.196.134
		+	</code>
		+
		+	Помимо командного режима, ''nslookup'' поддерживает и интерактивный – запустите ее без параметров, и вас встретит приглашение командной строки, где возможности тестирования DNS гораздо шире.
		+
		+	Вторая утилита – ''dig'' – выдает более подробную информацию согласно секциям DNS-ответа. Она менее удобна в повседневной жизни, зато позволяет лучше понять работу протокола DNS и более точно определить точки возникновения ошибок.
		+
		+	Одной из полезных особенностей этой утилиты является возможность задать в переменной окружения '''LOCALRES''' путь к альтернативному файлу вместо '''resolv.conf'''. Эта переменная никак не влияет на работу других программ, так что с помощью ''dig'' можно проверить работоспособность нового файла либо использовать альтернативный в особых случаях. '''LXF'''

Crazy Rebel в 09:28, 21 октября 2008

2008-10-21T09:28:27Z

← Предыдущая		Версия 09:28, 21 октября 2008
Строка 139:		Строка 139:
	Теперь машины нашей локальной сети будут получать нужные адреса при запросах к «зоне» local (при условии, что в настройках в		Теперь машины нашей локальной сети будут получать нужные адреса при запросах к «зоне» local (при условии, что в настройках в
	качестве DNS-сервера указан наш), ну а запросы к другим зонам будут обслуживаться как в случае кэширующего сервера.		качестве DNS-сервера указан наш), ну а запросы к другим зонам будут обслуживаться как в случае кэширующего сервера.
		+
		+	====Служить бы рад...====
		+
		+	Рассмотрим еще один случай. Предположим, что пользователи вашей небольшой локальной сети активно работают с ресурсами, имена которых обслуживаются зоной вашего провайдера. Безусловно, использование кэширующего DNS-сервера поможет разгрузить и DNS-сервер провайдера, и ваш интернет-канал. Однако можно поступить еще лучше – настроить свой ''BIND'' в качестве slave-сервера для зоны провайдера. Подчиненный (slave) сервер DNS предназначен для резервирования основного сервера, т.е. он тоже занимается обслуживанием зоны, но с той разницей, что файл зоны он берет не с диска, а скачивает с основного (master) сервера. Если данные этой зоны меняются не часто, то, единожды загрузив файл зоны (выполнив трансфер зоны), вы сможете
		+	самостоятельно обслуживать запросы к ней без обращений к DNS-серверу провайдера. Описывается slave-зона столь же легко:
		+
		+	<code>
		+	zone “your.provider.ru” {
		+	type slave;
		+	file “/var/bind/slaves/your.provider.ru.db”;
		+	masters { 1.2.3.4; }; # IP-адрес провайдерского DNS-сервера
		+	};
		+	</code>
		+
		+	После перезагрузки сервера (например, командой ''rndc reload'') у вас должен появиться указанный файл. Вручную создавать его не нужно; только позаботьтесь, чтобы каталог '''/var/bind/slaves''' принадлежал пользователю '''BIND''' или, как минимум, был доступен ему на запись. Теперь ваш сервер сможет авторитативно (то бишь компетентно, официально) отвечать на запросы, касающиеся зоны http://your.provider.ru, без дополнительных обращений к серверу провайдера. (Нужно заметить, что зачастую администраторы DNS-серверов по соображениям безопасности запрещают передачу зоны на произвольные узлы. Если это ваш случай, то попросите провайдера разрешить трансфер для вашего адреса – в конце концов, он тоже заинтересован, чтобы его сервер не
		+	беспокоили по пустякам.)
		+
		+	Кстати, то, что мы получили, на самом деле не настоящий slave-сервер, поскольку ни одна из NS-записей зоны http://your.provider.ru на него не ссылается. Так что «чужие» о нашем сервере ничего не узнают и не смогут им пользоваться – а нам оно и не надо... Если же вы настраиваете полноценный slave-сервер для делегированного вам поддомена, то укажите его в файле зоны в качестве NS-сервера наряду с основным:
		+
		+	<code>
		+	@ IN NS ns.mydomain.ru.
		+	IN NS slave.mydomain.ru.
		+	</code>
		+
		+	Теперь клиенты будут обращаться случайным образом как к основному, так и к подчиненному серверу, распределяя нагрузку. А в случае выхода из строя основного, slave-сервер, как ему и положено, возьмет обслуживание зоны на себя.
		+
		+	====Другая точка зрения====
		+
		+	Допустим, у вас есть делегированный вам домен http://mydomain.ru, который обслуживается вашим DNS-сервером. И здесь может возникнуть две интересные задачи. Во-первых, иногда нужно скрыть некоторую информацию от любопытных глаз, предоставляя ее лишь избранным. Например, ваша компания оказывает услуги доступа в Интернет, и вы хотите, чтобы ваш FTP-сервер посещали лишь ваши абоненты. (Да, это делается настройкой самого FTP-сервера, но было бы неплохо, чтобы посторонние о нем даже и не знали...) Можно ли предоставить адрес вашего сервера только пользователям конкретного домена?
		+
		+	Во-вторых, в локальной сети, как правило, используются «серые» IP-адреса, и обращение к «внешним» по отношению к ней ресурсам связано с трансляцией адресов. Но если ресурс работает на машине с несколькими сетевыми интерфейсами и доступен в том числе и по «серому» адресу, то такая трансляция уже несколько избыточна. Можно ли возвращать пользователям локальной сети «серый» адрес в ответ на запрос, не вынуждая их использовать альтернативные имена типа http://inner.mydomain.ru или тот же «домен» local?
		+
		+	В случае использования ''BIND9'' ответы на оба вопроса будут положительны. В нем появилась одна замечательная штука – оператор '''view'''. Он позволяет разграничить «виды» одной и той же зоны для разных групп клиентов. Выглядит это примерно так:
		+
		+	<code>
		+	view “clients” {
		+	match-clients { 1.2.3/24; };
		+	zone “mydomain.ru” {
		+	type master;
		+	file “/etc/bind/mydomain.clients.db”;
		+	};
		+	. . . прочие зоны . . .
		+	};
		+	view “others” {
		+	match-clients { any; };
		+	zone “mydomain.ru” {
		+	type master;
		+	file “/etc/bind/mydomain.db”;
		+	};
		+	. . . прочие зоны . . .
		+	};
		+	</code>
		+
		+	Такими настройками мы выделили два «вида» – для наших клиентов (сеть 1.2.3.0/24) и всех остальных. Осталось лишь подготовить различные файлы одних и тех же зон для разных «видов», и задача будет решена. Обратите внимание, что если вы приняли решение использовать «виды», то не должно быть ни одного оператора zone, не входящего в какой-нибудь оператор '''view'''.

Crazy Rebel в 09:22, 21 октября 2008

2008-10-21T09:22:19Z

← Предыдущая		Версия 09:22, 21 октября 2008
Строка 42:		Строка 42:

	Теперь поговорим о сервере. Наиболее распространенным пакетом, обеспечивающим работу службы DNS на Unix-подобных системах, в настоящее время является BIND (Berkeley Internet Name Domain). Посмотрим, какая от него может быть польза, даже если вы не располагаете собственным доменом.		Теперь поговорим о сервере. Наиболее распространенным пакетом, обеспечивающим работу службы DNS на Unix-подобных системах, в настоящее время является BIND (Berkeley Internet Name Domain). Посмотрим, какая от него может быть польза, даже если вы не располагаете собственным доменом.
		+
		+	{{Врезка
		+	\|Заголовок=Скорая помощь
		+	\|Содержание=Если, несмотря на все шаманство с '''resolv.conf''', разрешение имен идет как-то не так, загляните в '''/etc/nsswitch.conf''', в строку '''hosts'''. Там указан порядок поиска доменных имен: '''files''' означает файл '''/etc/hosts''', '''dns''' – поиск с помощью DNS-клиента. Возможно, тут и кроется проблема?
		+	\|Ширина=200px}}

	Установка сложностей никаких не представляет – даже если ''BIND'' не включен в состав вашего дистрибутива изначально, его, как правило, несложно найти в официальном репозитории. Скажем, в Ubuntu достаточно одной команды – ''sudo aptitude install bind9'', и спустя 300 килобайт трафика один из лучших DNS-серверов в мире будет трудиться вам на благо.		Установка сложностей никаких не представляет – даже если ''BIND'' не включен в состав вашего дистрибутива изначально, его, как правило, несложно найти в официальном репозитории. Скажем, в Ubuntu достаточно одной команды – ''sudo aptitude install bind9'', и спустя 300 килобайт трафика один из лучших DNS-серверов в мире будет трудиться вам на благо.
Строка 107:		Строка 112:

	Соответствующий файл '''0.168.192.in-addr.arpa.db''':		Соответствующий файл '''0.168.192.in-addr.arpa.db''':
		+
		+	{{Врезка
		+	\|Заголовок=Маленькие шалости с DNS
		+	\|Содержание= Думаю, вы уже поняли, что собственный DNS-сервер позволяет и немножко пошалить. Например, что помешает нам создать master-зону '''microsoft.com'''? Вот наши пользователи удивятся, когда вместо http://www.microsoft.com попадут на http://linux.org ! Главное – не переусердствовать, ведь потерять доверие других людей – это уже совсем не шутки...
		+	\|Ширина=300px}}

	<code>		<code>

Crazy Rebel в 09:17, 21 октября 2008

2008-10-21T09:17:13Z

← Предыдущая		Версия 09:17, 21 октября 2008
Строка 31:		Строка 31:

	<code>		<code>
-	nameserver 1.2.3.4	+	nameserver 1.2.3.4
-	nameserver 4.3.2.1	+	nameserver 4.3.2.1
	</code>		</code>

Строка 38:		Строка 38:

	Помимо упомянутой опции '''nameserver''', в '''resolv.conf''' могут задавать ся и некоторые другие параметры, но сейчас они нам не слишком интересны. Подробности ищите на странице ''man resolv.conf(5)''.		Помимо упомянутой опции '''nameserver''', в '''resolv.conf''' могут задавать ся и некоторые другие параметры, но сейчас они нам не слишком интересны. Подробности ищите на странице ''man resolv.conf(5)''.
		+
		+	===BIND: Узелок на память===
		+
		+	Теперь поговорим о сервере. Наиболее распространенным пакетом, обеспечивающим работу службы DNS на Unix-подобных системах, в настоящее время является BIND (Berkeley Internet Name Domain). Посмотрим, какая от него может быть польза, даже если вы не располагаете собственным доменом.
		+
		+	Установка сложностей никаких не представляет – даже если ''BIND'' не включен в состав вашего дистрибутива изначально, его, как правило, несложно найти в официальном репозитории. Скажем, в Ubuntu достаточно одной команды – ''sudo aptitude install bind9'', и спустя 300 килобайт трафика один из лучших DNS-серверов в мире будет трудиться вам на благо.
		+
		+	Самое интересное то, что свежеустановленный ''BIND'' уже готов к работе в качестве кэширующего DNS-сервера. То есть он не отвечает ни за какую зону (за исключением localhost), но способен разрешать поступающие к нему запросы, сохраняя ответы в локальном кэше. При повторном запросе ответ уже будет возвращен из кэша, за счет чего достигается некоторая экономия трафика и времени.
		+
		+	Для управления сервером (его исполняемый файл носит название ''named'') можно использовать стандартные средства вашего дистрибутива (скажем, сценарий '''/etc/init.d/bind9'''; в других дистрибутивах он может называться просто bind или named). Помимо этого, существует специальная утилита ''rndc'' (замечу, что, поскольку во время работы она взаимодействует с уже запущенным демоном ''named'', то запускать его она как раз и не умеет). Чаще всего вы будете сталкиваться с командой ''rndc reload [zone]'', позволяющей перезагрузить зону (или все зоны) после внесения изменений. Состояние сервера вернет вам ''rndc status''. Введите ''rndc'' без параметров, и вы узнаете обо всех ее возможностях. Чтобы начать использовать свой DNS-сервер, укажите его IP-адрес в '''/etc/resolv.conf'''.
		+
		+	====Пусть работает трактор в поле...====
		+
		+	Как нетрудно догадаться, чтобы получить IP-адрес, соответствующий имени http://www.yandex.ru, кэширующий сервер будет вынужден итеративно обращаться к различным серверам, начиная с корневого, пока не получит искомое. Для крупного DNS-сервера это вполне нормальный режим работы (заодно пополняющий кэш сведениями о промежуточных серверах), но в нашей небольшой сети мы хотели бы максимально снизить нагрузку и трафик. В случае с ''BIND'' львиную долю нагрузки можно переложить на плечи DNS-сервера нашего провайдера, указав в конфигурационном файле '''named.conf''' (в Ubuntu его можно найти в '''/etc/bind''') параметр '''forwarders''' в разделе '''options''':
		+
		+	<code>
		+	options {
		+	. . . другие опции . . .
		+	forwarders {
		+	1.2.3.4; # IP-адрес DNS-сервера провайдера
		+	};
		+	// forward only;
		+	};
		+	</code>
		+
		+	Теперь все запросы, на которые наш сервер не сможет ответить из своего кэша, он будет пересылать DNS-серверу провайдера (можно указать и несколько), ожидая от последнего уже готового ответа. Раскомментировав строку '''forward only''', мы вообще запретим нашему серверу самостоятельно искать ответ, даже если ни один из forward-серверов наш запрос не удовлетворит.
		+
		+	Раз уж мы здесь, рассмотрим конфигурационный файл '''named.conf''' чуть подробнее. Синтаксис у него, как видите, «Си-подобный», поэтому не забывайте завершать каждую опцию и блок точкой с запятой. Блок options содержит общие для сервера опции, для каждой обслуживаемой зоны должен присутствовать блок zone (обратите внимание на зоны, по умолчанию присутствующие в '''named.conf'''; зона «.» – подсказка серверу, где искать корневые серверы, чтобы с чего-то начать).
		+
		+	====Своя зона====
		+
		+	Что еще можно сделать, имея собственный DNS-сервер? Ну, например, мы можем создать «локальную» зону для наших внутренних узлов. Скажем, чтобы по адресу http://webserver.local открывалась наша внутренняя интернет-страничка, а ftp://ftpserver.local вел на FTP-сервер. Конечно, можно прописать необходимые соответствия в '''/etc/hosts''' на каждом узле локальной сети, но зачем так усложнять себе жизнь?
		+
		+	Итак, в '''named.conf''' добавляем описание нашей «зоны»:
		+
		+	<code>
		+	zone “local” {
		+	type master;
		+	file “/etc/bind/local.db”;
		+	};
		+	</code>
		+
		+	И в файл '''/etc/bind/local.db''' заносим информацию о наших узлах:
		+
		+	<code>
		+	$TTL 3d
		+	@ IN SOA admin.ns.local. (
		+	1 ; Порядковый номер
		+	2d ; Период обновления
		+	1h30m ; Повторение попытки
		+	1w ; Устаревание slave-зоны
		+	1h ) ; Время жизни отрицательных ответов
		+	;
		+	IN NS ns.local.
		+	ns IN A 192.168.0.254
		+	webserver IN A 192.168.0.2
		+	ftpserver IN CNAME webserver.local.
		+	</code>
		+
		+	В подробности вдаваться не будем – если интересно, ответы на все вопросы вы найдете в замечательной документации (''man 5 named.conf''). Пока достаточно знать, что '''A'''-запись ставит в соответствие имя хоста его IP-адресу, а '''CNAME'''-запись позволяет указать для хоста дополнительное имя. NS указывает на DNS-сервер, отвечающий за данную зону (т.е. на наш сервер). Полные доменные имена обязательно должны заканчиваться точкой, имена без точки будут дополняться именем зоны. Ну и нужно знать про еще одну запись – '''PTR''', отвечающую за «обратное» разрешение (т.е. поиск доменного имени по IP-адресу), для которого нужно создать еще и '''in-addr.arpa'''-зону:
		+
		+	<code>
		+	zone “0.168.192.in-addr.arpa” {
		+	type master;
		+	file “/etc/bind/0.168.192.in-addr.arpa.db”;
		+	};
		+	</code>
		+
		+	Соответствующий файл '''0.168.192.in-addr.arpa.db''':
		+
		+	<code>
		+	$TTL 3d
		+	@ IN SOA admin.ns.local. (
		+	1 ; Порядковый номер
		+	2d ; Период обновления
		+	1h30m ; Повторение попытки
		+	1w ; Устаревание slave-зоны
		+	1h ) ; Время жизни отрицательных ответов
		+	;
		+	IN NS ns.local.
		+	2 IN PTR webserver
		+	254 IN PTR ns
		+	</code>
		+
		+	Фигурирующую в самом начале SOA-запись можно, не вдаваясь в особые подробности, скопировать из какого-нибудь файла-примера – в ней задаются преимущественно различные таймауты, и значения по умолчанию обычно неплохо подходят. Точка с запятой начинает
		+	комментарий.
		+
		+	На всякий случай замечу, что файлы зон вы вольны называть как душе угодно. Просто для удобства принято, чтобы имя файла соответствовало обслуживаемой зоне: сразу видно, за что именно тот или иной файл отвечает, и не обязательно сверяться с '''named.conf'''.
		+
		+	Теперь машины нашей локальной сети будут получать нужные адреса при запросах к «зоне» local (при условии, что в настройках в
		+	качестве DNS-сервера указан наш), ну а запросы к другим зонам будут обслуживаться как в случае кэширующего сервера.

Crazy Rebel: Новая: ==Служба доменных имен== :Система доменных имен поистине вездесуща. Она обеспечивает нам комфортную ра...

2008-10-21T09:05:56Z

Новая: ==Служба доменных имен== :Система доменных имен поистине вездесуща. Она обеспечивает нам комфортную ра...

Новая статья

==Служба доменных имен==
:Система доменных имен поистине вездесуща. Она обеспечивает нам комфортную работу в Сети, хотя на нее редко кто обращает внимание в повседневной жизни. '''Сергей Супрунов''' попытается исправить эту несправедливость.

===DNS: Cвязующее звено Интернета===

Четырехбайтная адресация, лежащая в основе IP-протокола, на котором, помимо всего прочего, зиждется сеть Интернет, удоб-
на для операционных систем, но слишком тяжела для слабого и изнеженного человеческого мозга. Поэтому «записная книжка», из
которой в любое время можно было бы узнать, что сайт http://linuxformat.ru нужно искать по адресу 88.212.196.134, а почту для http://mail.ru отправлять на 194.67.23.20, всегда будет востребована.

Поначалу с ролью такой «записной книжки» превосходно справлялся простой текстовый файл '''HOSTS.TXT'''. За его формирование отвечал Сетевой информационный центр Стенфордского института, а администраторы и пользователи периодически скачивали его по FTP. Но по мере роста числа компьютеров, объединенных в единую сеть, такое решение стало абсолютно неэффективным.

В конечном итоге DNS (Domain Name System, система доменных имен) уверенно и, похоже, надолго, заняла место службы, снабжающей
нас информацией о том, какой же IP-адрес соответствует интересующему нас доменному имени. Основным преимуществом DNS является ее распределенная природа – информация не концентрируется в одном месте, а разбросана по всему Интернету в соответствии с иерархической структурой пространства доменных имен.

Во главе этой иерархии размещается так называемый корневой домен, обозначаемый одиночной точкой. Из этого корня «растут» домены первого уровня – '''ru''', '''uk''', '''com''', '''net''', '''org''' и т.д. Для реального использования доступны домены, начиная со второго уровня. Внутри домена могут размещаться как отдельные хосты, так и поддомены. Например, http://www.ibm.com – хост в домене '''ibm.com''', а http://austin.ibm.com – поддомен.

Здесь нужно ввести еще одно понятие – «зона». Зоной называют область пространства имен домена, которая администрируется независимо от остального пространства имен. Жесткой привязки к делению на поддомены здесь нет – поддомен может обслуживаться как автономная единица, т.е. иметь свою зону (в этом случае говорят о делегировании поддомена), а может входить в родительскую зону.

Так как же DNS позволяет узнать IP-адрес того или иного хоста, например, http://www.yandex.ru? Выглядит это примерно так. Клиент отправляет запрос близлежащему DNS-серверу (обычно это сервер провайдера, но мы увидим далее, что можно запустить и собственный). Этот сервер в общем случае не знает требуемый IP, и даже не представляет, где его искать. Поэтому обращается к одному из корневых DNS-серверов. Корневой сервер физически не в силах держать информацию обо всех доменах третьего (да даже и второго) уровня, так что все, что он может сделать, это послать нас... правильно, к DNS-серверу первого уровня, который обслуживает зону '''ru'''.

В дела отдельных доменов и этот сервер не вникает, так что адреса конкретных узлов не обслуживает. Зато он знает, какой DNS-сервер отвечает за домен http://yandex.ru. Туда он нас (точнее, сервер нашего провайдера) и отправит. А вот DNS-сервер домена http://yandex.ru уже просто обязан вернуть нам IP-адрес входящего в его зону ответственности хоста. Ну или послать... на этот раз просто послать, если искомый хост не существует в природе.

Таким образом, за каждый домен может отвечать свой администратор, настраивая DNS-сервер для его обслуживания, а вышестоящим
серверам достаточно знать, что и кому они делегировали. За счет этого и обеспечивается потрясающая масштабируемость, сделавшая службу DNS столь эффективной.

====Желание клиента – закон====

Начнем наше знакомство с клиентской части. Реализована она в виде стандартной библиотеки, и используем мы ее, можно сказать, ежеминутно, сами того не замечая. Если точнее, то используют ее те приложения, с которыми мы работаем – браузеры, FTP- и почтовые клиенты, различные сетевые серверы, да практически любые приложения, работающие в сети.

Настраивается клиент с помощью файла '''/etc/resolv.conf'''. В большинстве случаев достаточно указать там DNS-серверы, адреса которых предоставляет вам провайдер:

<code>
nameserver 1.2.3.4
nameserver 4.3.2.1
</code>

В современных дистрибутивах эта операция зачастую выполняется через графический интерфейс. Если для настройки сети используется DHCP-клиент, то он, как правило, и осуществляет «редактирование» '''/etc/resolv.conf'''. Т.е. обычный пользователь сталкивается с данным файлом не часто. Тем не менее, полезно знать, куда заглянуть в случае проблем.

Помимо упомянутой опции '''nameserver''', в '''resolv.conf''' могут задавать ся и некоторые другие параметры, но сейчас они нам не слишком интересны. Подробности ищите на странице ''man resolv.conf(5)''.