Библиотека сайта rus-linux.net
Приемы работы в Ubuntu.
Глава 10: Сервер малого офиса / домашнего офиса
Оригинал: "Ubuntu Hacks: Chapter 10 - Small Office/Home Office Server"
Авторы: Кайл Ранкин, Джонатан Оксер, Билл Чайлдерс (Kyle Rankin, Jonathan Oxer, Bill Childers)
Дата публикации: June 2006
Перевод: Н.Ромоданов
Дата перевода: ноябрь 2010 г.
Совет # 100: Создаем сервер доменных имен
Запустите свой собственный сервер DNS, чтобы отображать имена хостов в IP-адреса.
Система доменных имен (DNS) представляет собой распределенную службу каталогов, с помощью которой имена хостов, используемые для машин, отображаются в адреса IP и наоборот. Система DNS позволяет использовать имена просто как "указатели" на фактическое местонахождение серверов в сети, предоставляя для этого понятное и удобное для восприятия человеком имя, даже в случае, если фактический адрес IP изменяется.
Разбираемся с DNS за 60 секунд
Причина, почему DNS называется "распределенным" сервисом, состоит в том, что нет ни одной машины, на которой находилась бы полная таблица поиска для всей сети интернет. Вместо этого DNS функционирует как дерево с корневыми серверами, которые разбросаны по всему миру и которые обслуживают домены верхнего уровня (top-level domain - TLD), например, .com. По ссылке http://www.root-servers.org вы можете найти более подробную информацию о корневых серверах, используемых в текущий момент. Область, за которую отвечает каждый сервер имен, называется зоной, а подробная информация о каждой зоне хранится, как правило, в конфигурационном файле, который называется zonefile.
Сервера DNS каждого уровня могут делегировать полномочия, относящиеся к части своей зоны, серверам, находящимся по иерархии ниже, так корневые сервера делегируют полномочия для .au некоторым австралийским серверам имен, которые, в свою очередь, делегируют полномочия для .com.au другим серверам имен, которые, затем, делегируют полномочия для .oxer.com.au серверам имен Джонатана Оксера (Jonathan Oxer), которые, в конце концов, обрабатывают запрос, относящийся к конкретному хосту, например, jon.oxer.com.au, и отображают их в адреса IP. Система имеет большую иерархию и при помощи делегирования полномочий прямо к конкретному месту в интернете позволяет обрабатывать данные об именах конкретных хостов.
Обратите внимание, что ничто не мешает вам создать сервер доменных имен и поместить в него любые данные, какие вы хотите: вы можете создать запись www.microsoft.com, которая будет указывать на сервер www.oreilly.com, если вы так захотите, и если вы будете использовать этот сервер DNS, то вы как раз это и увидите. Но до тех пор, пока ваш сервер DNS не будет являться частью глобального пространства имен, полномочиями которого управляют корневые сервера имен, никто никогда не увидит записи, которые вы в него записали. Недостаточно просто создать сервер имен: вам необходимо иметь домены, которые должны "делегировать" сверху вашему серверу имен соответствующие полномочия так, чтобы другие компьютеры знали, что ваш сервер имеет полномочия управления в этом домене. В противном случае, вы просто обслуживаете зону, к которой никто не имеет возможность обратиться, т. е. так называемую orphan zone.
Тем не менее, есть полностью альтернативные пространства имен DNS, которые были созданы за пределами обычных корневых серверов, но они доступны только тем, кто использует специально переконфигурированные пространства имен. С помощью этих альтернативных пространств имен вы можете зарегистрировать домены в зонах .indy, .parody, .job и даже .www, но вы будете отрезаны от подавляющего большинства пользователей сети.
Подсказка
И последнее, будьте очень внимательны относительно того, что, строго говоря, домены, на самом деле, должны заканчиваться символом "." (точка). Несмотря на то, что заключительная точка подразумевается, большинство пользователей интернет даже не догадываются, что она должна здесь быть. Попробуйте сами: укажите браузеру адрес www.oreilly.com. и в конце укажите точку, вы увидите, что произойдет. Если бы каждый записывал бы все технически правильно, то во все адреса URL должны были бы быть включены завершающие точки, но все будет работать и так, как есть, поскольку сервера DNS предполагают, что мы просто ленимся и относится к нашим URL, как если бы там была добавлена точка. Для большинства это просто незначащая формальность, но как только вы начинаете настройку своего собственного сервера DNS, точка становится важной, так что имейте это в виду.
На самом деле схема DNS очень сложна и ее, в действительности, нельзя понять всего лишь за 60 секунд, но важно помнить, что она иерархически структурирована в виде дерева и начинается с символа "." (точка), что ее зоны делегируются вниз по иерархии серверов доменных имен и уточняются на каждом уровне и что зоны могут отображать имена хостов в адреса IP и наоборот.
Авторитетный и рекурсивный поиск
Когда компьютеру нужно найти имя и преобразовать его в адрес IP, то есть два варианта поиска, которые можно использовать.
Авторитетный поиск (authoritative lookup) представляет собой запрос к серверу имен, который может ответить в соответствие со сведениями относительно того, что есть и чего нет в его зоне. Например, если вы делаете запрос корневым серверам относительно имени www.oreilly.com, они не смогут достоверно ответить, поскольку на них не содержится конкретная информация о хостах этой зоны. Тем не менее, запрос на собственные сервера O'Reilly вернет достоверный ответ. Сервера имен в хостинговых компаниях обычно затрачивают большую часть своего времени для предоставления достоверных ответов о зонах, которыми они управляют.
Рекурсивный поиск (recursive lookup) представляет собой запрос серверу имен, который ничего конкретно не знает о запрашиваемом имени хоста, но который прежде, чем он вернет его компьютеру, сделавшему запрос, может использовать дерево DNS с тем, чтобы получить ответ. Сервера имен, имеющиеся у провайдеров, обычно тратят большую часть своего времени для выполнения рекурсивного поиска от имени пользователей, а не на предоставления достоверных ответов.
В действительности, авторитетный и рекурсивный поиск являются абсолютно различными операциями, поэтому есть специализированные программы для создания серверов DNS для каждого типа запросов. Не редки случаи, когда на сервере DNS запускаются два различных пакета для отдельной обработки авторитетных и рекурсивных запросов.
Установка BIND9
Для серверов DNS общего назначения хорошим выбором может быть BIND (Berkeley Internet Name Daemon), который является очень популярным сервером DNS и изначально может выполнять как авторитетный, так и рекурсивный поиск:
$ sudo apt-get install bind9
Если Вам нужен только рекурсивный сервис DNS, то этого вам будет достаточно. Если вы заглянете в файл /etc/bind/db.root, вы увидите, что в BIND есть самые свежие адреса IP корневых серверов имен, которые позволяют ему прямо "из коробки" просматривать делегированную информацию и делать рекурсивные запросы от имени других компьютеров.
Вы можете протестировать его с помощью машины с Linux, при этом можно не менять настройки сервера имен, а просто указать адрес вашего сервера DNS и с помощью команды nslookup, которая есть в пакете dnsutils выполнить ручной поиск:
jon@jbook:~$ nslookup jon.oxer.com.au 192.168.0.2 Server: 192.168.0.2 Address: 192.168.0.2#53 Non-authoritative answer: Name: jon.oxer.com.au Address: 202.91.207.154
Как видите, в результате был возвращен неавторитетный ответ, поскольку серверу для ответа пришлось обратиться к внешнему источнику. Если все сработало, вы можете на своих рабочих станциях отредактировать файл /etc/resolv.conf и затем для поиска использовать ваш сервер DNS.
Создание авторитетной зоны прямого просмотра
Авторитетные сервера имен бывают двух типов: главные (master) и подчиненные (slave). При конфигурировании главного сервера имен настройки зоны, которой он управляет, вносятся непосредственно вручную, а подчиненный сервер запрашивает имена зон и периодически просит главный сервер с помощью операции переноса зоны (zone transfer) обновлять его кэш локальной копии зоны. В этом совете вы узнаете, как настроить главный сервер имен.
Подсказка
На самом деле, ничего не запрещает вам запускать все ваши сервера имен как главные; до тех пор, пока вы поддерживаете их конфигурации в синхронизированном состоянии, все будет прекрасно работать. Внешние машины, осуществляющие поиск, не знают о различии между главным и подчиненным серверами: настройка главный/подчиненный делается исключительно для удобства использования.
Большая часть конгфигурационных настроек главного сервера BIND находится в файле /etc/bind/named.conf. Вместо того, чтобы его корректировать непосредственно, лучше хранить все ваши настройки в виде отдельных файлов и "включать" их в основную конфигурацию. По умолчанию в Ubuntu есть файл /etc/bind/named.conf.local, который вы можете использовать для определения собственных зон.
Чтобы хранить все аккуратно, создайте поддиректорий, в котором вы будете сохранять файлы ваших зон:
$ sudo mkdir /etc/bind/zones
Теперь для вашей зоны создадим файл зоны с именем самой зоны, например, /etc/bind/zones/example.com.hosts, и поместим в файл, например, следующее:
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2001061407 ; serial
10800 ; refresh
3600 ; retry
432000 ; expire
38400 ) ; ttl
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
example.com. IN MX 30 mail.example.com.
www.example.com. IN A 202.91.207.152
mail.example.com. IN A 202.91.207.152
Первая строка представляет собой начало описания зоны (Start Of Authority, SOA)
(подробнее о том, что такое Start Of Authority, можете
прочитать здесь, прим.редактора.) ).
Она содержит название зоны example.com., указание на основной сервер имен зоны —
ns1.example.com и почтовый адрес главного администратора зоны — hostmaster.example.com.
Обратите внимание на то, что в адресе администратора зоны символ @ заменен точкой: BIND трактует
первый
элемент в строке как имя пользователя, а оставшуюся часть — как домен. Последующие значения
указывают, как зона должна обрабатываться другими серверами имен, например, как долго могут
кешироваться записи. (Пояснения вы также найдете по приведенной выше
ссылке, прим.редактора.)
В записях NS указываются сервера имен, которые авторитетны для данной зоны, в записи MX указывается хост, осуществляющий обмен почтой в этом домене, и его приоритет, имеющий значения от 1 до 100 (меньшее число указывает на более высокий приоритет), а в записях A задается отображение конкретных имен хостов в адреса IP.
Обратите внимание, что в файле зоны все полные имена хостов завершаются точкой, и это правило следует выполнять везде, где указываются имена хостов. При вводе в адресную строку браузера вы можете не указывать точку в конце адреса URL, но в файле зоны вы не должны опускать точку! Если вы не поставите в конце точку, то BIND сделает предположение, что имя хоста не завершилось, и добавляет к нему домен, в результате у вас получится, например, адрес www.example.com.example.com. Вы можете воспользоваться таким поведением BIND, намеренно не указывая имя хоста целиком и указывая только первую часть имени хоста без точки:
www IN A 202.91.207.152
Чтобы BIND знал о вашем новом файле зоны, вам необходимо отредактировать файл /etc/bind/named.conf.local и добавить к нему в конце следующую запись:
zone "example.com" {
type master;
file "/etc/bind/zones/example.com.hosts";
};
Затем перезагрузите BIND:
$ sudo /etc/init.d/bind9 reload
Теперь, если вы попытаетесь сделать запрос к серверу имен относительно хоста, находящегося в вашей зоне, вы увидите, что в результате показан ваш адрес IP, а отметка "nonauthoritative" ("неавторитетный") будет отсутствовать:
jon@jbook:~$ nslookup www.example.com 192.168.0.2 Server: 192.168.0.2 Address: 192.168.0.2#53 Name: www.example.com Address: 202.91.207.152
Правила брандмауэра
Если вы настраиваете брандмауэр [Совет # 69], вам нужно добавить определенные правила, разрешающие DNS запросы от внешних машин. По умолчанию DNS запросы отправляются на порт 53 по протоколу UDP или, если размер пакета превышает 512 байта, то - по протоколу TCP. Поэтому на сервере DNS вы должны разрешить через брандмауэр доступ по протоколам UDP и TCP на порт 53.
| Назад | Оглавление | Приехали! |