Руководство системного администратора • третье издание { h h y с п п т п р



Pdf просмотр
страница41/82
Дата12.11.2016
Размер7.94 Mb.
Просмотров12667
Скачиваний0
ТипРуководство
1   ...   37   38   39   40   41   42   43   44   ...   82
471

Аргумент сервис — JTO ИМЯ сервиса, определенное в базе данных IANA
(Internet Assigned Numbers Authority — агентство по выделению имени уникальных параметров протоколов Internet); получить дополнительную информацию можно в параграфе 13.3 или по адресу www.iana.org/num- bers.htm. Аргумент протокол должен быть равен либо t c p , либо udp. Аргумент
имя — это домен, на который ссылается запись SRV. Аргумент приоритет
имеет тот же смысл, что ив записи MX. Аргумент вес используется для распределения нагрузки между несколькими серверами, порт — это номер порта, на котором выполняется сервиса сервер —
это имя сервера, предоставляющего данную услугу. В ответ на запрос к записи SRV обычно возвращается запись А сервера Имя сервера, равное '* означает, что сервис недоступен на данном узле. Если вес равен 0. то специального распределения нагрузки не требуется. Ниже показан пример, взятый из документа RFC2052 (где определена запись SRV) и адаптированный для домена cs colorado.edu: f t p . сер О 0 21 f t p - s e r v e r . c s . C o l o r a d o . e d u .
; доступ к сервису закрыт имя сервера О 0 79
; одна четверть соединений о Ослу жива е т с я старым компьютером ат р и четвертин о вы м s s h . t c p SRV О 1 2 2 o l d - s i o w - o o x . c s - c o l o r a a o . e d u .
SRV О 3 22 n e w - f a s t o o x . c s . c o l o r a d o . e d u .
; основной сервер доступен через порт ВО,
; аре з ер в н ы й — через орт наново м компьютере О 0 8 0 w w w - s e r v e r . c s . c o l o r a d o . e d u .
SRV 1 0 0 8 0 0 0 n e w - f a s t - b o x . c s . c o l o r a d o . e d u .
; в адресной строке можно указывать как o . e a u , таки d u h t t p . t c p . w w w SRV О 0 80 w w w - s e r v e r . c s . c o l o r a a o . e d u .
SRV 1 0 0 8 0 0 0 n e w - f a s t - t o o x - c s . c o i o r a d o . e d u .
; все остальные сервис ы блокированы ООО
В JTOM примере демонстрируется применение как аргумента вес (сервис
SSH). таки аргумента приоритет (сервис HTTP). Будут задействованы оба сервера SSH. причем нагрузка между ними распределяется в соответствии с производительностью серверов. Резервный сервер HTTP используется точько в том случае, когда основной сервер не функционирует. Сервис finger недоступен на данном узле, как и все остальные сервисы, имена которых не упомянуты явно. Тот факт , что демон finger отсутствует в базе данных DNS. не означает, что он не выполняется просто его нельзя найти средствами DNS. Раньше в базе данным DNS существовала запись WKS (well-known services — известные сервисы). Вместо того чтобы переадресовывать запрашивающего на узел, который предоставляет указанный сервис в рамках домена, она содержала список всех сервисов, поддерживаемых заданным узлом. Эта запись является практически бесполезной и. к тому же, считается рискованной сточки зрения безопасности, поэтому она не получила распространения
472
Чость II Роботов сетях
Компания Microsoft использует в Windows 2000 стандартные записи SRV. но способ их внедрения в базу данных DNS является нестандартными несовместимым с документацией. Записи ТХТ Запись ТХТ добавляет в базу данных DNS произвольный текст. Например, в нашей базе данных имеется следую шал запись, идентифицирующая нашу организацию
I N TXT " U n i v e r s i t y o f CO, B o u l d e r C a m p u s . C S D e p t " Эта запись непосредственно следует за записями SOA и NS зоны "cs.colo- rado.edu.". наследуя таким образом от них поле имя.
Записи ТХТ используются также в сочетании с записью RP, которая содержит контактную информацию для связи с человеком, отвечающим за функционирование узла (в записи SOA указан лишь его электронный адрес. Запись ТХТ имеет такой формат
имя [ccl] IN ТХТ информация ...
Все информационные элементы должны быть заключены в кавычки. Это может быть как одна строка, таки несколько строк, каждая из которых заключена в кавычки. Будьте предельно внимательны — пропущенная закрывающая кавычка может привести к разрушению базы данных DNS. У записей ТХТ нет внутреннего порядка. Следовательно, не стоит пытаться добавить в базу данных единый информационный блок, представленный в виде нескольких записей ТХТ: в ответ иа запрос демон named может возвращать их в произвольном порядке. Записи ресурсов IPv6
IPv6 — это новая версия протокола IP. Процесс принятия спецификации длится уже более десяти лет. Своим появлением протокол IPv6 обязан существовавшей в то время острой потребности в дополнительных адресах. Однако решения этой проблемы, считавшиеся временными, — протокол
CIDR, система NAT и строгий административный контроль над адресным пространством — оказались столь успешными, что массовый переход к стандарту IPv6 вряд ли произойдет в скором будущем. Если не появится какое-нибудь суперпопулярное приложение, работающее только с IPv6 (нли компания Microsoft не сделает этот протокол стандартным в Windows), тов ближайшие несколько лет системные администраторы не захотят иметь дело с иным форматом адресов Ряд анапитиков полагает, что чаша весов склонится в пользу IPv6 благодаря новому поколению мобильных телефонов, имеющих
I Р-адреса. Хотя мы не ожидаем широкого распространения протокола IPv6, будет все же полезно описать влияние разрядных адресов на DNS. Изменению подвергнутся записи Аи, но это относительно простые перемены в сравнении с задачей внедрения совершенно новой концепции совместного владения адресами. Сетевой плате, которой соответствует адрес IPv6, принадлежит лишь несколько битов адреса, ноне все они. Другие биты делегируются вышестоящим провайдерам в попытке сделать перенумерацию и смену провайдера простой задачей Однако реализация этого механизма довольно сложна.
Глово 16. Системо доменных имен
473
В IPv6 эквивалент записи А первоначально назывался АААА, поскольку адреса IPv6 в четыре раза длиннее, чем простые адреса. Когда появилась схема разделенного управления адресами, организация I E T F стандартизировала два новых типа записей А (для перевода имен компьютеров в адреса) и D N A M E (ДЛЯ передачи частей адреса другим организациям. Прототипом для записи D N A M E послужила запись CNAME, с помощью которой, как было показано выше, обеспечивалась поддержка сетевых масок, не проходящих по границе байтов. Запись А задает адрес, но при этом учитывается, что часть старших битов должна бьггь получена из другого источника. Мы не будем подробно рассматривать механизмы поиска имен в IPv6, поскольку они е ш е недостаточно четко определены организацией IETF, да и у нас ие очень большой опыт работы сними. В следующих двух разделах излагается лишь суть этой совершенно новой методики. Записи А 6 Формат записи Аб таков
иия_узла I t t l ] IN А6 чмсло_отложенных_С)итов адрес ссылка
Например: a n c h o r I N А 6 0 3 f f e : 8 0 5 0 ; 2 0 1 : 9 : а 0 0 : 2 0 f f : f e 8 l : 2 b 3 2 . a n c h o r I N A 6 4 8 : : 9 : a 0 0 : 2 0 f f : f e 8 l : 2 b 3 2 p r e f i x . n i y i s p . n e t . Обе записи задают одни и тот же адрес IPv6 для узла anchor. В первом случае адрес полностью определена во втором — 48 префиксных битов делегируются узлу prefix.myisp.net. Обратите внимание на то, что впервой записи в качестве ссылочного аргумента указана точка. Она означает, что никаких дальнейших ссылок не требуется. Модулю распознавания может потребоваться обратиться ко многим серверам имен, чтобы собрать полный разрядный адрес по цепочке записей А. Например, во второй из показанных выше записей наследующем уровне могут оказаться отложенными 47 битов, далее — 46 и т.д. Для получения ответов придется сделать 48 запросов. Добавьте эквивалентное число запросов DNSSEC, требуемых для проверки каждого компонента адреса, и получится кратное увеличение трафика при распознавании одного единственного имени Как видите, официальные спецификации не всегда просты и эффективны. На практике из сорока восьми возможных уровней переадресации останутся два или три, но сама концепция открывает интересное поле для атак вида "отказ от обслуживания. Более подробная (и менее предвзятая) документация содержится в каталоге doc пакета BIND 9. Записи Обратное преобразование адресов IPv6 в доменные имена основано на использовании традиционных записей PTR и записей нового типа — DNAME. Записи PTR связывают локальные биты адреса IPv6 с конкретным сетевым именем, а записи D N A M E определяют, какие из оставшихся частей адреса каким организациям принадлежат. В IPv4 зоны обратного преобразования располагались в домене in- addr.arpa, а зоны прямого преобразования — в других ветвях дерева доменов например, в доменах " c o m " или "edu"). В IPv6 информация об обратном
469
Чость II Роботов сетях
преобразовании более рассредоточена. Часть ее находится в домене iri6.arpa, а часть хранится в зонах прямого преобразования. Компоненты имен в домене in-addr.arpa представляют собой байты адреса. В IPv6 эта схема обобщена, и компонентам именн разрешается представлять произвольные части адреса. Такие адресные секции могут быть длиной от I до 128 битов они известны как битовые строки. Битовые строки записываются посредством специального синтаксиса. Рассмотрим его на конкретном примере. Все однонаправленные адреса IPv6 начинаются с трехбитового префикса 001. Чтобы записать этот префикс языком битовых строк, нужно взять двоичное число 001 и дополнить его незначашим битом, чтобы длина цепочки была кратна четырем 0010. В результате получаем шестиадцатеричную цифру 2; у нее три бита значащих и один — незначащий. Финальная строка записывается так
\ 1*2/3] Обратная косая черта, квадратные скобки и литерах ограничивают каждую битовую строку. Содержательная часть строки — это последовательность шестнадцатеричных цифр (в данном случае одна цифра — 2) и спецификатор длины (/3). Последний указывает, сколько битов, представленных шестнадцатеричными цифрами, нужно учитывать. Это необязательный компонент. Если он отсутствует, длина битовой строки вычисляется на основании количества шестнадцатеричных цифр, умноженного на 4 (в данном случае длина строки составляет 4 бета. Даже если битовые строки оканчиваются на границе шестнадцатеричных цифр, желательно указывать спецификатор длины, иначе читатели файлов ослепнут, пытаясь подсчитать длину больших строк. Самые левые биты строки являются наиболее значащими. Дополнительные биты, присоединяемые к самой правой цифре, просто не учитываются. Все они должны равняться нулю. Поскольку все однонаправленные адреса IPv6 имеют общий префикс 001, самый верхний домен в ветви обратного преобразования — \[x2/3j|.ip6.arpa. А вот более сложный пример. Ниже записано три разных представления одного адреса первый разв цельном виде, второй — с разделением натри части (3/45/80), третий — на четыре (3/13/32/80)". По мере перераспределения блоков их шестнадцатеричное представление полностью меняется, хотя в основе остаются те же самые биты. Чтобы получить двоичное представление чисел, воспользуйтесь утилитой be.
\ [ x 3 f f e 8 0 5 0 0 2 0 1 0 0 0 9 0 a 0 0 2 0 f f f e 8 1 2 b 3 2 / 1 2 8 ] . i p f e . a r p a .
\ t x 0 0 0 9 0 a 0 0 2 0 f f f e 8 1 2 b 3 2 / 8 0 1 . \ [ x f f f 4 0 2 8 0 1 0 0 8 / 4 5 1 . \ 1 x 2 / 3 ] . i p 6 . a r p a .
\ [ x 0 0 0 9 0 a 0 0 2 0 f f f e 8 1 2 b 3 2 / 8 0 1 . \ [ x 8 0 5 0 0 2 0 1 / 3 2 ] , \ [ x f f f 0 / 1 3 ]
. \ [ x 2 / 3 ] Л р багра. Как ив случае зон домена in-addr.arpa в IPv4, отдельные числа читаются слева направо, а компоненты адреса (блоки, разделенные точками) — справа налево. Первый компонент второй и третьей из показанных выше строк — это локальная часть адреса. Он представляет младшие 80 битов адреса и состоит из шестнадцатеричных цифр 0 0 0 9 0 a 0 0 2 0 f f f e 8 1 2 b 3 2 . Приведем еще раз те же самые строки с выделенной локальной частью адреса Не упустите из виду тот факт, что адреса IPv6 сами по себе имеют определенную внутреннюю структуру. В параграфе 13.4 рассказывалось о том, из каких компонентов состоит адрес IPv6 и что они означают
Глово 16. Системо доменных имен
475

\ [ x 3 f f e B 0 5 0 0 2 0 1 0 0 0 9 0 a 0 0 2 0 f £ f e 8 l 2 b 3 2 / 1 2 8 ] . i p 6 . a r p a .
\ [ x 0 0 0 9 0 a 0 0 2 0 f f f e 8 l 2 b 3 2 / B 0 j Л [ x f f f 4 0 2 8 0 1 0 0 8 / 4 5 ] . \ [ x 2 / 3 ] . i p 6 . a r p a .
S [ x 0 0 0 9 0 a 0 0 2 0 f f f e 8 1 2 b 3 2 / 8 0 ] Л [ x 8 0 5 0 0 2 0 1 / 3 2 | . \ [ x f f f 0 / 1 3 ]
. 4 [ x 2 / 3 ] . i p 6 . a r p a . Спецификатор / 4 5 во второй строке говорит о том, что в шестнадцате- ркчной цепочке f f f 4 0 2 8 0 1 0 С 8 45 битов из ми являются значащими. Очевидно, разработчики стандартов считают, что для иас это развлечение — вбивать все эти фрагменты в файлы без ошибок. Записи D N A M E делегируют адресные секции другим серверам имен. Формат записей имеет следующий вид
битовая строкс! [ t t l ] IN DNAME целевой доыен
Идея состоит в том. что разными частями адреса управляют разные организации. Вам принадлежат 80 битов, вашему провайдеру — собственный блок, его провайдеру — свой и т.д. Процесс делегирования иллюстрируется на примере показанных ниже фрагментов. Здесь используется четырехблоко- вое представление приводившегося выше адреса, при котором цепочка делегирования проходит от корневого сервера к серверу провайдера и далее к серверу искомого домена. В данном примере директивы SORIGIN залают контекст каждой записи. Эти фрагменты взяты из зонных файлов трех разных организаций корневого сервера домена ip6.arpa, сервера my-isp.nei и сервера my-domain.com. Таким образом, они не относятся к единой конфигурации какого-то одного узла. Корневой сервер домена ip6.arpa — \[x2/3].ip6.arpa — делегирует заданный битовый адрес серверу my-isp.nei, для чего в зониый файл включаются следующие строки
; передача адресного префикса серверу \ 1 x 2 / 3 ] - i p o . a r p a .
\ [ x f f f 0 / 1 3 ] I N DNAME i p 6 . m y i s p . n e t . При этом создается нечто вроде псевдонима для заданного адреса
\Ixffro/13|.\[x2/3|.ip6.arpa, и этот псевдоним указывает на строку "*ip6.mv- isp.nel.". Провайдер, в свою очередь, передает битовый сегмент адреса серверу my-domain.com. помещая такие строки в файл своей зоны ip6.niy- isp.net:
; передача адресного префикса серверу G I N x p 6 . m y - i . s p . n e t .
\ Г x 8 0 5 0 0 2 0 1 / 3 2 1 I N DNAME i p b . m y - d o m a i n . n e t . Здесь формируется имя "\|x80500201/321 ip6 my-isp.nei.", которое, раскрываясь из предыдущей записи DNAME, образует битовый префикс адреса
IPv6. Эти 48 битов являются синонимом имени ip6.my-domain.com В зонных файлах домеиа ip6.my-domain.com посредством записи PTR устанавливается привязка для оставшейся части адреса
S O R I G I N i p 6 . m y - d o m a i n . n e t .
\ [ x 0 0 0 9 0 a 0 0 2 0 f f £ e 8 1 2 b 3 2 / 8 0 ] I N PTR h o s t . m y - a o m a i n . n e t . Мы советуем не беспокоиться по поводу делегирования, если у вас один провайдер и система расположена водном месте. Просто включите весь
128-разрядиый адрес в файлы зон прямого и обратного преобразования. Если у провайдера произойдут какие-го изменения, он сообщит о них и несложно будет самостоятельно отразить их в нескольких файлах.
476
Чость II. Роботе в сетях
Протокол IPv6 еше относительно молод, по крайней мере сточки зрения ввода его в эксплуатацию Адресные канцелярии только начинают распределять адреса. Локальная часть адреса IPv6 никогда не меняется, и это прекрасно. С другой стороны, большинство организаций также редко меняет своего провайдера, поэтому биты, получаемые от провайдера, можно смело включать в зонные файлы. Напишите небольшой сценарий на Perl, который поменяет префикс всех адресов, если вы решите перейти к другому провайдеру. Команды в файлах зон Закончив изучение базовых записей о ресурсах, перейдем к знакомству с командами, которые вставляются в зонный файл для модификации последующих записей. Таких команд четыре
S o R I G I N да ядом е на иыя_файла

STTL стандартное_значение
5GENERATE аргументы
Команды обязаны начинаться впервой колонке и занимать отдельную строку. Когда демои named читает зоииый файл, он добавляет стандартное имя домена (источник) к любому имени, которое не является полностью определенным. Первоначально источником служит домен, указанный в соответствующей инструкции z o n e в файле named.conf. Эту установку можно изменить в зонном файле посредством директивы $0RIGIN. Использование относительных имен вместо полных позволяет сэкономить много времени на вводе данных и делает зонные файлы гораздо более удобными для восприятия. Например, все записи зон обратного преобразования для сети класса В с группой подсетей могут находиться водном зонном файле, где директивы $ORIGIN устанавливают контекст каждой подсети Инструкция вида
S O R I G I N 2 4 3 . 1 3 8 . 1 2 8 . i n - a d d r . a r p a будет предшествовать записям подсети 243. Во многих организациях в зонные файлы включаются директивы
$ INCLUDE, позволяющие разделять зонные базы данных иа логические блоки или хранить ключи шифрования в отдельном файле с ограниченными правами доступа. Указанный в директиве файл включается в базу данных в том месте, где стоит директива.
Директива STTL залает стандартное значение для поля ill записей, идущих после иее. Раньше это значение можно было определить только в записи
SOA В B I N D 8 рекомендуется размешать директиву $TTL вначале зонных файлов. В BIND 9 это обязательное требование, и те файлы, в которых директива отсутствует, ие будут загружены. В BIND 9 применяется концепция, известная как согласование времени жизни все записи одного типа, принадлежащие одному узлу, должны иметь одинаковое значение TTL. Используемое значение берется у первой записи, относящейся к данной паре узел/тип.
Директива 5GENERATE, относительно новая конструкция в BIND 8. позволяет легко создавать наборы похожих записей. В основном она применяется при работе с записями C N A M E в файлах зон обратного
Глово 16. Системо доменных имен
477
преобразования, когда маски подсетей не проходят по границе байтов в адресе (см. документ RFC23I7). Формат директивы таков.
S GENERATE начала -конец [ шаг левыйарг тип правый_арт• f колшентарий]
а генерируемые строки будут иметь следующий вид
левый_арг тип правый_арг
Поля начало и конец определяют диапазон значений счетчика цикла. Для каждого значения в диапазоне создается одна строка. Ссылка на счетчик цикла в левом и правом аргументах осуществляется посредством метасимво- ла S. Если задан шаг, счетчик цикла будет изменяться на указанную величину.
Поле тип определяет тип записи. В настоящее время поддерживаются только записи CNAME, PTR и NS, причем лишь в BIND S. В BIND 9 эта поддержка, возможно, появится в будущем. Конкретный пример приводился при описании специального применения записи CNAME. Зона Адрес 127.0.0.1 обозначает исходный компьютер и должен всегда соответствовать имеии 'iocalhost^oKflL?b«b/ii_rfo.Me«.'". например localhost.cs.colo- rado.edu. В некоторых организациях данный адрес связывается с именем "localhost.", как будто оно является частью корневого домена подобная конфигурация неверна. Если забыть сконфигурировать зону localhost, то компьютеры в системе начнут запрашивать информацию о самих себе у корневых серверон. Последние в настоящее время принимают так много подобных тапросов, что их администраторы рассматривают вопрос об установлении соответствия между именем localhost и адресом 127.0.0.1 на верхнем уровне. Пример правильной конфигурации зоны localhost приведен в параграфе. Связующие записи ссылки между зонами У каждой зоны свой набор файлов данных, серверов имени клиентов. Но зоны должны быть соединены друг с другом, чтобы получалась связная иерархия К примеру, домен cs.colorado.edu является частью домена colo- rado.edu, ив должна существовать связь между ними. Поскольку отсылки всегда возвращаются в направлении от родительских доменов к дочерним, серверу имен необязательно знать что-то о доменах точнее, зонах, расположенных выше в иерархии DNS. В тоже время серверы родительского домена должны хранить адреса серверов имен всех своих поддоменов. По сути, в ответ на внешние запросы могут возвращаться отсылки только к тем серверам имен, которые известны в родительской зоне. Говоря языком DNS, родительская зона должна содержать записи NS лля каждой делегируемой юны. Нов них указываются доменные имена, а не адреса, поэтому родительский сервер должен иметь способ как-то преобразовать эти имена, те. либо выполнить обычный запрос (если при этом не возникает циклическая зависимость, либо обратиться к собственным копиям соответствующих записей А. Реализовать это требование можно двумя путями хранить все необходимые записи либо использовать усеченные зоны.
478
Чость II Роботов сетях
В первом случаев базу данных родительской зоны включаются требуемые записи NS и А. Например, зонный файл домена Colorado edu может содержать следующие записи ,
; информация оп од доменах d o . e d u .
I N
NS p i p e r . c s . c o o r a d o . e d u .
IN
NS n s . x o r . c o m . ее. ее . C o l o r a d o . e d u .
; связующие записи . 1 5 1 p i p e r . св. ее Посторонние" записи А называются связующими, так как они в действительности не принадлежат данной зоне. Они присутствуют лишь для того, чтобы связать новый домен с деревом имен Internet. Отсутствие или некорректность связующих записей приведет к тому, что часть адресного пространства окажется недоступной и пользователи, пытающиеся обратиться к нему, будут получать сообщения об ошибке "host unknown" (неизвестный узел. Распространенной ошибкой является включение связующих записей для тех доменных имен, которые этого ие требуют. В частности, в показанном выше примере адрес домеиа ns.xor.com может быть найден путем обычного запроса. Запись А для него поначалу будет просто лишней, но впоследствии окажет "медвежью" услугу, если адрес домена по какой-то причине изменится. Правило гласит, что записи А должны включаться только для узлов, которые находятся в текущем домене или одном из его поддоменов. Существующие версии B I N D игнорируют ненужные связуюшие записи, а их присутствие фиксируется в журнальном файле как ошибка. Описанная схема представляет собой стандартный способ соединения зон между собой, но она требует, чтобы дочерние зоны держали связь с родительскими зонами и уведомляли их об изменениях своих серверов имен. Однако в связи стем, что такие зоны часто контролируются разными организациями, это становится утомительным трудом, требующим объединения усилий нескольких администраторов. Как следствие, в реальной жизни подобная конфигурация часто оказывается устаревшей. Второй способ обслуживания межзоиных связей заключается в использовании усеченных зон. Они полностью поддерживаются в BIND 8. ио были также доступны ив (там о иих говорилось как об экспериментальной возможности. Усеченная зоиа, по сути, представляет собой тоже самое, что и подчиненная зона, но содержит только записи NS. Усеченные зоиы прекрасно работают в BIND 8, где данные различных зон смешиваются в памяти, ио вдела обстоят по-другому. В BIND 9 усеченные зоны должны быть одинаково сконфигурированы на главных и подчиненных серверах родительской зоны, которые сами по себе достаточно сложно поддерживать в согласованном состоянии. Поэтому лучше всего просто держать связь с родительским домеиом и проверять его конфигурацию хотя бы несколько разв год. С помощью команды dig можно узнать, какие из ваших серверов в настоящий момент известны родительскому домену. Сначала введите команду d i g родительский домен пв
Глово 16. Системо доменных имен
479
чтобы узнать серверы имен родительского домена. Выберите один из них и введите d i g бсервер ииеи.родительский_доыен дочернийдсыен па чтобы получить список собственных общедоступных серверов имеи. Усеченные зоны особенно полезны в ситуации, когда внутренняя адресация зоны основана иа частном адресном пространстве (см. докумеит
RFC 1918) и необходимо поддерживать синхронизацию с делегированными зонами. Пример содержится в каталоге /src/conf/recursive дистрибутива
BIND 8. Следует упомянуть о некоторых особенностях усеченных зон. Усеченные зоны не содержат авторитетных копий зонных данных, и усеченные серверы не должны указываться в записях NS зоны. Поскольку усеченные серверы не упоминаются в записях NS, они не уведомляются автоматически при изменении зонных данных. Нужно либо добавить параметр a l s o - n o t i f y в конфигурацию главных серверов, либо просто дождаться истечения периода обновления зоны, указанного в записи SOA. Теоретически демону named ненужны копии записей NS зоны, если он не может получить соответствующие записи А. Но он способен сам себя загрузить, используя адрес главного сервера, содержащийся в файле named.conf Зачем ограничивать себя записями NS? Почему бы просто не быть вторичным сервером поддомена? Этот прием тоже работает. Но если каждый сервер родительского домена будет одновременно сервером дочернего домена, то нижестоящие серверы никогда не будут получать отсылок Серверы родительского домена станут предоставлять подломе ну все функции DNS. Возможно, это именно то. что нужно, а возможно — нет
16.12. Обновление файлов зон Когда в домен вносится изменение (например, добавляется или удаляется компьютер, следует откорректировать файлы данных на главиом сервере. Кроме того, надлежит увеличить порядковый номер в записи SOA для этой зоны и выполнить команду ndc reload, которая просигнализирует демону named о необходимости принять изменения. Можно просто уничтожить и перезапустить демон (команда ndc restart), но это вызовет уничтожение кэшированных данных, полученных из других доменов. В ранних версиях BIND для управления демоном named применялись сигналы и команда kill, но когда у разработчиков перестало хватать сигналов, появилась команда ndc. которая исправила ситуацию. Скорее всего, в будущем сигналы вообще перестанут поддерживаться (за исключением сигнала HUP. вызывающего повториое чтение конфигурационного файла, и сигнала TERM, приводящего к выгрузке демона, поэтому рекомендуем пользоваться командой. Обновленные зонные данные будут переданы подчиненным серверам немедленно, поскольку параметр n o t i f y включен по умолчанию. Если же по какой-то причине он был отключен, подчиненным серверам придется дожидаться, пока истечет период обновления, установленный в записи SOA зоны (обычно от одного до шести часов. В случае, когда необходима более срочная корректировка, можно выполнить на подчиненном сервере команду



Поделитесь с Вашими друзьями:
1   ...   37   38   39   40   41   42   43   44   ...   82


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал