Библиотека сайта rus-linux.net
Запуск named
Пакет named обеспечивает DNS на большинстве Unix-машин. Это серверная программа, первоначально разработанная для BSD, чтобы обеспечить сервис имен для клиентов и, возможно, для других серверов имен. BIND Version 4 довольно долго поставлялся почти во всех дистрибутивах Linux. Сейчас вместо него поставляется новая версия 8, которая имеет много отличий от предыдущей. Особо надо отметить введение поддержки динамических модификаций DNS, сообщений изменения DNS, улучшение эффективности и новый синтаксис файла конфигурации.
Этот раздел требует понимания принципов работы DNS. Если такого понимания нет, обратитесь к разделу "Как работает DNS".
Пакет named обычно запускается при начальной
загрузке системы. Реализации BIND до Version 8 берут информацию из файла
конфигурации /etc/named.boot и различных файлов,
которые отображают имена домена к адресам. Последние называются зональными
файлами (zone files). Версии BIND после Version 8
используют /etc/named.conf
вместо
/etc/named.boot
.
#
|
Пакет named запустится и прочитает
named.boot и заданные в нем зональные файлы. Он пишет
свой process ID в файл /var/run/named.pid
в ASCII,
загружает все зональные файлы с первичного сервера и начинает слушать порт
53 в ожидании запросов DNS.
Файл named.boot
Файл конфигурации BIND до Version 8 был очень прост. BIND Version 8 имеет
совсем другую структуру файла настройки, чтобы использовать новые свойства.
Имя файла настройки сменилось с /etc/named.boot
на
/etc/named.conf
. Мы сосредоточимся на
конфигурировании старой версии, потому что многие дистрибутивы ее еще
используют, но рассмотрим и отличия. К тому же мы рассмотрим, как
преобразовать старый файл named.conf
в новый.
Файл named.boot вообще маленький и содержит мало
данных, но указывает на главные файлы, содержащие зональную информацию и
хранит указатели на другие серверы имен. Комментарии в файле начинаются с
символов # или ; и заканчиваются в конце строки. Прежде чем мы обсудим формат
named.boot
более подробно, рассмотрим типовой файл
для vlager в
примере 6-8.
Пример 6-8. Файл named.boot для vlager
; ; /etc/named.boot file for vlager.vbrew.com ; directory /var/named ; ; domain file ;----------------- cache . named.ca primary vbrew.com named.hosts primary 0.0.127.in-addr.arpa named.local primary 16.172.in-addr.arpa named.rev |
Рассмотрим каждую инструкцию индивидуально. Ключевое слово
directory сообщает named
, что все имена файлов, упоминаемых позже в этом файле, например,
зональные файлы, размещены в каталоге /var/named
.
Ключевое слово primary загружает информацию в named. Эта информация принимается из главных (master) файлов, определенных как последние параметры. Эти файлы представляют DNS-записи ресурсов, которые мы рассмотрим позже.
В этом примере мы конфигурируем named как первичный
(primary) сервер имен для трех доменов, как
обозначено тремя инструкциями primary.
Первая из них предписывает named действовать как
первичный сервер для vbrew.com, принимая
зональные данные из файла named.hosts
.
Ключевое слово cache должно присутствовать
фактически на всех машинах, управляющих сервером имен. Оно инструктирует
named использовать кэш и загружать имена
(root name server hints) из определенного файла кэша
(в нашем примере named.ca
). Это будет рассмотрено
чуть позже.
Вот список наиболее важных параметров, которые Вы можете использовать в
named.boot
:
- directory
Опция определяет каталог, в котором расположены зональные файлы. Имена файлов в других параметрах могут быть даны относительно этого каталога. Несколько каталогов могут быть определены несколькими словами directory. Стандарт файловой системы Linux предполагает, что это
/var/named
.- primary
Эта опция берет имя домена и имя файла как параметры, объявляя локальный сервер авторитетным для заданного домена. Как первичный сервер named загружает зональную информацую из данного главного файла.
Всегда будет по крайней мере одна запись primary в каждом файле boot, используемая для обратного отображения сети 127.0.0.0, которая является кольцевым интерфейсом (loopback).
- secondary
Инструкция берет имя домена, список адресов и имя файла как параметры. Это объявляет локальный сервер вторичным главным (secondary master) сервером для заданного домена.
Вторичный сервер хранит авторитетные данные относительно домена, но не собирает их из файлов. Вместо этого он пробует загружать их с первичного сервера. IP-адрес по крайней мере одного первичного сервера должен быть передан named в списке адресов. Локальный сервер входит в контакт с каждыми из них до успешного получения зональной базы данных, которая затем будет сохранена в резервном файле заданном как третий параметр. Если ни один из первичных серверов не отвечает, зональные данные будут восстановлены из резервного файла.
Затем named пытается обновить зональные данные с регулярными интервалами. Этот процесс объясняется позже в связи с типом записи ресурса SOA.
- cache
Эта опция берет имя домена и имя файла как параметры. Этот файл содержит root server hints, который является списком записей, указывающих на корневые серверы имен. Будут распознаны только записи NS и A. Параметр
domain
должен быть именем корневого домена.Эта информация критична для named. Если инструкции cache нет в файле boot, named не будет использовать локальный кэш вообще. Эта ситуация резко ухудшит эффективность и увеличит сетевую загрузку, если следующий сервер сделает запрос не о машине в локальной сети. Кроме того, named не будет обращаться к корневым серверам, а значит, не сможет преобразовать никакие адреса кроме тех, которые авторитетны для него. Исключение из этого правила: сервера пересылки (см. ниже опцию forwarders).
- forwarders
Инструкция берет список адресов, разделенных пробелами как параметр. Адреса IP в этом списке определяют список серверов имен, которые named может спросить, если не может найти адрес сам в локальном кэше.
- slave
Инструкция делает сервер имен подчиненным (slave ). Он никогда не выполняет рекурсивные запросы самостоятельно, а только пересылает их на серверы, определенные в инструкции forwarders.
Есть два параметра, которые мы не будем описывать здесь: sortlist и domain . Еще две директивы могут также использоваться внутри этих файлов базы данных: $INCLUDE и $ORIGIN. Так как они редко нужны, мы не будем рассматривать их сейчас.
Файл host.conf в BIND 8
BIND Version 8 имеет много новых свойств, а с ними пришел и новый
синтаксис файла конфигурации. Старый named.boot
с простыми одиночными инструкциями был заменен на
named.conf
с синтаксисом, аналогичным gated,
похожий на C-синтаксис.
Новый синтаксис более сложен, но есть инструмент, который автоматизирует преобразование старого синтаксиса в новый. В пакете исходников BIND 8 есть perl-программа named-bootconf.pl , которая занимается этим преобразованием. Чтобы использовать этот инструмент, Вы должны иметь установленный интерпретатор perl.
# |
named.conf
, похожий на приведенный
в примере 6-9.Пример 6-9. Файл для BIND 8, эквивалентный файлу named.conf для vlager
// // /etc/named.boot file for vlager.vbrew.com options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "vbrew.com" { type master; file "named.hosts"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "16.172.in-addr.arpa" { type master; file "named.rev"; }; |
Если Вы внимательно его рассмотрите, то обратите внимание на то, что
каждая из инструкций named.boot
превратилась в
C-инструкцию, взятую в фигурные скобки "{ }".
Комментарии, которые в файле named.boot
начинались с точки с запятой (;), теперь обозначены как //.
Инструкция directory превратилась в параграф options с предложением directory.
Команды cache и primary преобразованы в зональные параграфы (zone) с типами ( type) предложений hint и master, соответственно.
Зональные файлы не должны измениться: их синтаксис остается неизменным. Новый синтаксис конфигурации учитывает много новых параметров, которые мы еще не рассмотрели.
Файлы базы данных DNS
Главные (Master) файлы, поставляемые с named, подобно named.hosts, всегда имеют домен, связанный с ними, называемый origin. Это имя домена, указанное с параметрами cache и primary. Внутри главного файла Вы можете определить домен и связанные с ним имена файлов. Имя, заданное в файле конфигурации, рассматривается абсолютно (absolute), если оно заканчивается одной точкой, иначе оно рассматривается относительно origin. Можно и прямо сослаться на origin знаком (@).
Данные, содержащиеся в главном файле, разделены на записи ресурсов (resource records, RRs). RRs самые маленькие модули информации, доступные через DNS. Каждая запись ресурса имеет тип. Например, A-записи отображают имя хоста на IP-адрес, а CNAME-записи связывают псевдоним для хоста с его официальным именем. Пример 6-11 показывает главный файл named.hosts для Virtual Brewery.
[
|
Поля отделяются пробелами или позициями табуляции. Запись может быть продолжена после перевода строки, если открывающаяся фигурная скобка стоит перед первым переводом строки и последнее поле сопровождается заключительной фигурной скобкой. Все между точкой с запятой и символом перевода строки игнорируется. Описание формата:
domain
Задает имя домена, к которому относится запись. Если никакое имя не задано, RR применяется к домену предыдущей RR.
ttl
Чтобы сервер имен обновлял информацию, RR ограничен по времени работы (ttl). Это поле определяет время в секундах, которое информация имеет силу после того, как была получена с сервера. Это десятичное число из восьми цифр.
Если значение ttl не дано, ему присваивается значение поля
minimum
предыдущей SOA-записи.class
Класс адреса, например, IN для адресов IP или HS для объектов в Hesiod-классе. Для TCP/IP Вы должны определить IN.
Если никакое поле класса не задано, берется класс предшествующей RR.
type
Описывает тип RR. Наиболее часто встречаются типы A, SOA, PTR и NS. Следующие разделы описывают различные типы RR.
rdata
Хранит данные, связанные с RR. Формат этого поля зависит от типа RR. Дальше это будет описано для каждого RR отдельно.
Дальше приведен частичный список RR, которые нужно использовать в файлах DNS.
- SOA
Описывает зону авторитета (SOA или "Start of Authority"). Эта запись сообщает о том, что записи после SOA RR содержат авторитетную информацию для домена. Каждый главный файл, включенный в инструкцию primary, должен содержать SOA-запись для этой зоны. Данные ресурса содержат следующие поля:
origin
Это каноническое имя хоста основного сервера для этого домена. Обычно задается как абсолютное имя.
contact
Это e-mail адрес человека, ответственного за поддержание домена, со знаком "@" замененным на точки. Например, если ответственный в Virtual Brewery janet, это поле содержит janet.vbrew.com.
serial
Номер версии зонального файла, выраженный как единственное десятичное число. Всякий раз, когда данные меняются в зональном файле, это число должно быть увеличено.
Серийный номер используется вторичными серверами, чтобы распознать, когда зональная информация была изменена. Чтобы оставаться на уровне современных требований, вторичные серверы запрашивают SOA-запись первичного сервера в определенные промежутки времени и сравнивают порядковый номер с кэшируемой SOA-записью. Если номер изменился, то вторичные серверы перенесут целую зону баз данных из основного сервера.
refresh
Определяет интервал в секундах, который вторичные серверы должны использовать между проверками SOA-записей основного сервера. Это десятичное число более, чем с восемью цифрами.
retry
Это число определяет интервалы, за которые вторичный сервер должен повторить соединение с основным сервером, если запрос или зональная регенерация терпит неудачу. Он не должен быть слишком маленьким, потому что даже временный отказ сервера или сетевая проблема могут потратить впустую все сетевые ресурсы. Один час или, возможно, полчаса оптимальное значение.
expire
Определяет время в секундах, после которого сервер должен отбросить все зональные данные, если невозможно было войти в контакт с основным сервером. Этот промежуток времени должен быть очень большим. Craig Hunt рекомендует 42 дня.
minimum
Задает по умолчанию значение ttl для исходных записей, которые точно не определяют его. Требует другого сервера, чтобы отбросить RR при проверки после определенного времени.
Ничего нельзя сделать со временем, после которого вторичный сервер попробует модифицировать зональную информацию. Значение
minimum
должно быть большим, особенно для LAN, где сетевая топология почти никогда не меняется. В случае, когда единственные RR могут часто изменяться, Вы можете приписывать им различные ttl.
- A
Ассоциирует IP-адрес с именем. Содержит адрес в dotted quad notation. Для каждого хоста должна быть только одна запись. Hostname, используемый в этой А-записи, считается служебным или каноническим hostname. Все другие hostname расцениваются как псевдонимы и должны быть отображены на канонический (canonical) hostname, используя запись CNAME. Если каноническое имя нашего хоста vlager, его и надо вписать в A-запись с его IP-адресом. Если мы связываем с этим адресом другое имя, например news, надо использовать запись CNAME, которая свяжет его с альтернативным именем.
- NS
Указывает на главный (primary) сервер подчиненной зоны. Содержит hostname сервера.
Вы встретите записи NS в двух ситуациях:- Когда Вы делегируете авторитет зависимой зоне.
- Внутри главной зональной базы данных зависимой зоны.
Запись NS определяет имена первичного и вторичного серверов для зоны. Эти имена должны быть разрешимы к используемому адресу. Иногда серверы не принадлежат к обслуживаемому домену, что порождает проблему: нельзя обратиться к серверу, пока не получен его адрес, но получить адрес нельзя, пока не обратимся к серверу (неоткуда). Можно конфигурировать специальные записи непосредственно на сервере имен родительской зоны. Они позволяют серверу из родительской области преобразовывать IP-адрес делегированного зонального сервера. Эти записи обычно названы приклеенными записями (glue records), поскольку они "склеивают" делегированную зону с родительской.
- CNAME
Ассоциирует псевдоним хоста с его каноническим hostname. Каноническиий hostname указан в файле, который обеспечивает А-запись, а псевдонимы просто связаны с этим именем CNAME-записью, но не имеют собственных записей.
- PTR
Этот тип записи используется, для того, чтобы соединить имена домена in-addr.arpa с именами хостов (hostnames). Это используется для обратного отображения IP-адресов к hostnames. Данное имя должно быть каноническим.
- MX
-
Эта RR объявляет преобразователь почты (mail exchanger) для домена. Для чего надо иметь преобразователи почты, рассказано в главе 17 . Синтаксис MX-записи следующий:
[
domain] [ttl] [class] MX preference host
Имя
host
объявляет преобразователь почты для доменаdomain
. Каждый преобразователь почты имеет целое числоpreference
, связанное с ним. Агент транспортировки почты, желающий доставить почту в домен, будет перебирать все хосты, не имеющие MX-записей в этом домене, пока все не пройдет успешно. Сначала будет проверяться тот хост, у которого самое низкое число, а затем все хосты по возрастанию числа. - HINFO
- Эта запись предоставляет информацию относительно аппаратных средств системы и программного обеспечения. Синтаксис этой записи:
[
domain] [ttl] [class] HINFO hardware software
Поле
hardware
идентифицирует аппаратные средства, используемые этим хостом. Имеются специальные соглашения, чтобы точно определить их. Список подходящих имен дан в "Assigned Numbers" (RFС 1340). Если область содержит пробелы, то ее содержимое надо заключить в двойные кавычки. Имена областейsoftware
используются операционной системой. Подходящее имя может быть выбрано из "Assigned Numbers" RFC.ЗаписьHINFO
для Intel Linux-машин может выглядеть примерно так:tao 36500 IN HINFO IBM-PC LINUX2.2
cevad 36500 IN HINFO ATARI-104ST LINUX2.0 jedd 36500 IN HINFO AMIGA-3000 LINUX2.0
Настройка сервера только для кэширования
Это особая конфигурация named
. Такой сервер в
действительности не обслуживает домен, а просто осуществляет переброску всех
запросов DNS, произведенных на Ваш компьютер. Преимущество этой схемы в том,
что она создает кэш. Так что только первый запрос для специфического
компьютера фактически будет послан серверу имен в Internet. Любой повторный
запрос будет обработан из кэша. Такая схема названа
caching-only. Это удобно при работе с Internet по
модему, как описано в главе 7 и
главе 8.
named.boot
для caching-only сервера имен
выглядит примерно так:
; named.boot file for caching-only server directory /var/named primary 0.0.127.in-addr.arpa named.local ; localhost network cache . named.ca ; root servers |
В дополнение к этому файлу named.boot
, Вы должны
установить файл named.ca
со списком корневых
серверов имен. Вы можете копировать и использовать для этой цели
пример 6-10. Другие
файлы не требуются.
Написание главных (Master) файлов
Примеры 6-10, 6-11, 6-12 и 6-13 дают типовые файлы для сервера имен сети brewery, размещенного на машине vlager. Это довольно простая конфигурация для одиночной локальной сети.
Файл кэша named.ca
в
примере 6-10
показывает типовые записи корневого сервера имен. Типичный файл кэша обычно
описывает около десятка серверов. Вы можете получать текущий список серверов
для корневого домена с помощью команды nslookup. Она
описана чуть ниже.
Пример 6-10. Файл named.ca
; /var/named/named.ca Cache file for the brewery. ; We're not on the Internet, so we don't need ; any root servers. To activate these ; records, remove the semicolons. ; ;. 3600000 IN NS A.ROOT-SERVERS.NET. ;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ;. 3600000 NS B.ROOT-SERVERS.NET. ;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ;. 3600000 NS C.ROOT-SERVERS.NET. ;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ;. 3600000 NS D.ROOT-SERVERS.NET. ;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ;. 3600000 NS E.ROOT-SERVERS.NET. ;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ;. 3600000 NS F.ROOT-SERVERS.NET. ;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ;. 3600000 NS G.ROOT-SERVERS.NET. ;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ;. 3600000 NS H.ROOT-SERVERS.NET. ;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ;. 3600000 NS I.ROOT-SERVERS.NET. ;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ;. 3600000 NS J.ROOT-SERVERS.NET. ;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ;. 3600000 NS K.ROOT-SERVERS.NET. ;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ;. 3600000 NS L.ROOT-SERVERS.NET. ;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ;. 3600000 NS M.ROOT-SERVERS.NET. ;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 |
Пример 6-11. Файл named.hosts
; /var/named/named.hosts Local hosts at the brewery ; Origin is vbrew.com ; @ IN SOA vlager.vbrew.com. janet.vbrew.com. ( 2000012601 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; ; local mail is distributed on vlager IN MX 10 vlager ; ; loopback address localhost. IN A 127.0.0.1 ; ; Virtual Brewery Ethernet vlager IN A 172.16.1.1 vlager-if1 IN CNAME vlager ; vlager is also news server news IN CNAME vlager vstout IN A 172.16.1.2 vale IN A 172.16.1.3 ; ; Virtual Winery Ethernet vlager-if2 IN A 172.16.2.1 vbardolino IN A 172.16.2.2 vchianti IN A 172.16.2.3 vbeaujolais IN A 172.16.2.4 ; ; Virtual Spirits (subsidiary) Ethernet vbourbon IN A 172.16.3.1 vbourbon-if1 IN CNAME vbourbon |
Пример 6-12. Файл named.local
; /var/named/named.local Reverse mapping of 127.0.0 ; Origin is 0.0.127.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 1 ; serial 360000 ; refresh: 100 hrs 3600 ; retry: one hour 3600000 ; expire: 42 days 360000 ; minimum: 100 hrs ) IN NS vlager.vbrew.com. 1 IN PTR localhost. |
Пример 6-13. Файл named.rev
; /var/named/named.rev Reverse mapping of our IP addresses ; Origin is 16.172.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 16 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; brewery 1.1 IN PTR vlager.vbrew.com. 2.1 IN PTR vstout.vbrew.com. 3.1 IN PTR vale.vbrew.com. ; winery 1.2 IN PTR vlager-if2.vbrew.com. 2.2 IN PTR vbardolino.vbrew.com. 3.2 IN PTR vchianti.vbrew.com. 4.2 IN PTR vbeaujolais.vbrew.com. |
Проверка настроек сервера имен
$
|
Программа nslookup делает запрос сервера имен,
определенного в файле resolv.conf
для
hostname
. Если этих серверов много,
nslookup выбирает один случайным образом.
Интерактивный режим является намного более удобным. Помимо поиска машин Вы можете сделать запрос для любого типа записи DNS и передачи всей зональной информации для домена.
При вызове без параметров nslookup отображает имя используемого сервера и входит в интерактивный режим. На приглашение > Вы можете указать любое имя домена, о котором хотите сделать запрос. По умолчанию посылается запрос для записей класса A, содержащих IP-адрес, связанный с именем домена.
Вы можете искать типы записи:
>
|
Здесь type
является одним из описанных
имен записи ресурса или ANY.
$ |
Сначала отображаются данные о сервере DNS, затем результат запроса.
No type A records found
. Вы можете заставить
программу сделать запрос для записей, отличных от A, командой
set type. Для получения SOA-записей из
unc.edu введите:
> |
> |
Используйте тип ANY, чтобы получить все записи ресурса, связанные с данным именем.
> |
Для просмотра списка всех команд введите help в nslookup.
Другие полезные инструменты
Есть несколько инструментальных средств, которые могут помочь Вам в решении задач. Здесь кратко описаны два таких средства.
Программа hostcvt помогает Вам построить
конфигурацию с нуля, преобразуя файл /etc/hosts
в
главные файлы для named. Она генерирует прямой (A) и
обратный (PTR) коды отображения и заботится о псевдонимах. Конечно, она не
сделает всю работу за Вас, поскольку Вам все еще нужно настраивать значения
времени ожидания в записи SOA или добавить MX-записи. Утилита
hostcvt входит в пакет BIND, но доступна и отдельно
с нескольких Linux FTP-серверов.
После установки сервера имен Вы должны проверить его конфигурацию. Некоторые хорошие инструментальные средства делают эту работу проще. Во-первых, это dnswalk, основанный на Perl. Во-вторых, nslint. Они оба обходят базу данных DNS, ищут общие ошибки и проверяют, что информация является непротиворечивой. Два других полезных инструментальных средства, host и dig, являются универсальными средствами для запроса базы данных DNS. Вы можете использовать эти инструментальные средства, чтобы вручную осматривать и диагностировать записи базы данных DNS.
Скорей всего, все эти средства доступны в откомпилированном виде. Утилиты dnswalk и nslint доступны в исходниках с http://www.visi.com/~barr/dnswalk и ftp://ftp.ee.lbl.gov/nslint.tar.Z. Утилиты host и dig доступны в исходниках с ftp://ftp.nikhef.nl/pub/network и ftp://ftp.is.co.za/networking/ip/dns/dig.
Назад | Глобальное оглавление | Вперед |
Как работает DNS | Локальное оглавление | Serial Line IP |