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



Pdf просмотр
страница43/82
Дата12.11.2016
Размер7.94 Mb.
Просмотров12673
Скачиваний0
ТипРуководство
1   ...   39   40   41   42   43   44   45   46   ...   82
489
упаковывает открытый ключ зоны, который был сгенерирован выше, устанавливает время жизни пакета равным 3600 с (один часа срок действия родительской сигнатуры — 10 дней начиная с текущего момента. Про1рамма dnssec- make keyset создает один выходной файл, mydomain.com. keyset. Его нужно послать в родительскую зону на подпись. Он содержит открытый ключи сигнатуры, созданные самими зонными ключами, чтобы родительская зона могла проверить открытый ключ дочерней зоны. В BIND 9 родительская зона использует программу dnssec-signkey для подписи упакованного набора ключей f Лпимес nlgnkey mydomain.com.keyset Kcom.+003+56789 Эта команда создает файл mydomain.com.signedkcy, который родительская зона ("com") возвращает дочерней зоне (mydomain.com) для включения в ее зонные файлы. В BIND 8 этой же цели служит программа dnssigner. Получив родительскую сигнатуру, можно начать подписывать реальные зонные данные. Этот процесс происходит следующим образом берется зонный фнйл и после каждого набора записей о ресурсах ставятся записи
SIG и NXT Первые содержат реальные сигнатуры, а второе обеспечивают подпись отрицательных ответов. В BIND 8 цифровые подписи ставятся посредством программы dnssigner. расположенной в каталоге contrib дистрибутива. В BIND 9 для этого используется программа dnssec-signzone. Например, команды
• dneaigner -or mydomeln.com - г ! db.mydomain -zo db.mydomain.signed -kl mydomain.com dsa 12345 -st fr BIND 6
• dnssec-signzone -o mydomain.com db.mydomain t BIND 9 читают зонный файл db.mydomain и создают подписанную версию зонного файла, называемую db.mydomain.signed. Первая из команд отображает также статистическую информацию о процессе простановки подписи (запрашивается параметром -st). В частности, сообщается, сколько времени заняло подписание, и показывается, какие записи были добавлены или удалены. Запись SIG содержит много информации е тип подписываемой записи используемый алгоритм (в данном случае — DSA); значение TTL для подписанного набора записей срок действия сигнатуры (в формате ггггММддччсссс);
• время простановки подписи (также в формате ггггМ Мддччсссс);
е идентификатор ключа (в данном случае — 12345), имя подписывающего (mydomain.com.); наконец, сама цифровая подпись. Чтобы можно было работать с подписанной зоной, найдите в файле named.conf зону my domain, ч от и измените в инструкции z o n e параметр f i l e так. чтобы он указывал на файла не db.mydomaln. В BIND S нужно также включить в инструкцию z o n e предложение pubkeys. Дело в том, что сервер BIND 8 проверяет зонные данные по мере их загрузки, поэтому он должен знать ключ заранее В BIND 9 такая проверка отсутствует сервер берет открытый ключ из записи KEY зоны и не требует никаких других настроек. Цифровые подписи прекрасно подходят для положительных ответов следующего вила "Вот адрес узла anchor.cs.colorado.edu, а вот сигнатура.
4Ь6
Чость II. Роботов сетях
доказывающая, что данные действительно поступили из домена cs.colorado.edu и эти данные корректны. Но что делать с отрицательными ответами наподобие "Нет такого узла При таких ответах обычно не возвращаются подписанные записи. В DNSSEC проблема решается за счет записей NXT, в которых указывается следующая запись зоны, отсортированной в каноническом порядке. Например, если после записи anchor.cs.colorado.edu идет запись awesome.cs.colorado.edu и поступает запрос к узлу anLhill.cs.coIorado.edu, в ответ будет получена запись NXT следующего вида a n c h o r . c s . c o l o r a d o . e d u . IN NXT a w e s o m e . c s . c o l o r a d o . e d u A MX NXT Она говорит о том, что сразу после имени "anchor" в зоне cs.colorado.edu следует имя "awesome", а имени "anchor" соответствует как минимум одна запись A, MX и NXT. Последняя запись NXT в зоне ссылается на первый узел. К примеру, запись NXT для имени zamboni.cs.colorado.edu ссылается на первую запись, те. на сам домен cs.colorado.edu: z a m b o n i . . cs . C o l o r a d o . e d u . IN NXT c s . c o l o r a d o . e d u A MX NXT Запись NXT возвращается также в том случае, если узел существует, ио запись запрашиваемого типа отсутствует. Если, скажем, запрос производится к записи LOC узла anchor, будет выдана та же самая запись NXT, что и показана выше, нов ней будут отображены только записи A, MX и NXT Изложенный здесь материал касается реализации DNSSEC в BIND 9.0,0 июль 2000). В пакет непрерывно вносятся значительные изменения, поэтому информация вряд ли будет оставаться корректной в течение долгого времени. Как всегда, точные детали можно узиатъ в справочных руководствах и документации к пакету BIND. Помня об этом, рассмотрим, какие потенциальные проблемы могут возникать в текущей, реализации DNSSEC. Спецификация DNSSEC не согласуется с понятиями кэширования и переадресации. В ней предполагается, что запрос сначала адресуется корневой зоне, а затем следует за отсылками вниз по дереву доменов в поисках ответа. Каждая подписанная зона в свою очередь подписывает ключи своих дочерних зон, и эта цепочка доверия надежна и нерушима. Если же в системе имеется переадресующий сервер, то первоначальный запрос попадает к нему, а не в корневую зону. Кэшируюший сервер, посылающий запросы через переадре- сующий сервер, будет перепроверять сигнатуры, поэтому ответы будут гарантированно надежными Но чтобы запрос имел успех, переадресующий сервер должен уметь возвращать все записи SIG и NXT, требуемые для проверки сигнатур. Серверы, не поддерживающие спецификацию DNSSEC, не умеют этого делать, ив документах RFC ничего не говорится о проблеме переадресации. В BIND 9 реализован ряд дополнительных механизмов помимо тех. которые определены документом RFC2535. поэтому кэшируюший сервер
BIND 9 способен работать по протоколу DNSSEC через переадресуюший сервер BIND 9. Таким образом, для одновременного использования протокола и переадресуюшего сервера во всей системе должен быть установлен пакет BIND 9 Это разновидность алфавитного порядка, при котором имена, стоящие выше в иерархии
DNS, указываются первыми. Например, в зоне cs.colorado.edu имя cs.coIorado.edu следует перед любым именем узел.cs.colorado.edu. В рамках одного уровня иерархии порядок сортировки — алфавитный. Гл о во. Системо доменных имен
491
Технология DNSSEC основана иа существовании инфраструктуры открытых ключей, которая на практике еше не реализована. Нет четкого способа заставить родительскую зону подписать ключи дочерней зоны нельзя послать письмо по адресу hosiname@com и получить в ответ подписанные ключи. Широкое распространение технология DNSSEC. вероятно, получит в ближайшие несколько лет. Сначала, очевидно, появятся подписанные версии корневых зон. Сигнатуры транзакции (технологии TSIG/TKEY) требуют меньше процессорного времени и меньшую полосу пропускания, чем системы аутентификации с открытым ключом. Но они гарантируют подлинность лишь отправителя, а не самих данных. Было бы неплохо взаимодействовать по технологии TSIG с сервером, реализующим протокол DNSSEC, однако невозможно установить подобные отношения с каждым сервером, так как технология TSIG требует ручной настройки DNS-файдов
Microsoft — плохо, UNIX — хорошо В Windows 2000 записи SRV используются для нахождения всего серверов имен, принтеров, файловых систем и т.д. Реализуя записи SRV. компания
Microsoft следовала спецификациям организации IETF, но способ вставки этих записей в базу данных DNS посредством защищенных динамических обновлений совершенно нестандартен. Компания использует разновидность сигнатур транзакций, называемую спецификацией GSS-TSIG. которая также основана на совместном секретном ключе. Ключ можно получить через систему Kerberos из центра распределения ключей. Вся прелесть в том, что реализация Kerberos, используемая компанией Microsoft, несовместима с открытой версией Kerberos 5.' И как прикажете называть тех, кто все это придумал Если нужно работать си использовать записи SRV, придется отказаться от существующей системы Kerberos и запустить сервер Win2K
Kerberos. Для многих организаций, где вся инфраструктура давно налажена, это становится неразрешимой проблемой. Возможно, компания Microsoft разработает какие-то свои расширения. Через неделю после того, как была выпущена ОС Win2K. число запросов, адресуемых корневым серверам DNS. резко возросло. Проведенные исследования показали, что неправильно сконфигурированные системы Win2K пытались динамически обновить корневые зоны или зоны верхнего уровня. В результате число запросов к корневому серверу А увеличилось более чем вдвое. Хуже того, когда запросы на обновление заканчивались неудачей, системы Win2K открывали соединение, чтобы запросить запись KEY и попытаться выполнить аутентифицированное динамическое обновление. У корневого сервера нет возможности отвечать на миллионы запросов об установлении соединения. На момент выхода книги в печать проблема все еще не была разрешена. Операторы корневых серверов тычут пальцами на сотрудников Microsoft, а те говорят "Нет, нет, это немы Тестирование и отладка Демон named располагает рядом встроенных средств отладки, основное из которых — великолепная подсистема журнальной регистрации. Можио также задавать уровни отладки в строке вызова демона или устанавливать их посредством команды ndc. Имеются команды, заставляющие демон вывести
487
Чость II. Работа в сетя*
статистику результатов своей работы в файл. С помощью программ dig и nslookup можно проверить, правильно ли функционирует механизм поиска имеи. Журнальная регистрация Возможности подсистемы журнальной регистрации демона named действительно впечатляют. Сервер BIND 4 использует систему Syslog для записи сообщений об ошибках и различных аномалиях В B I N D 8 концепция журнальной регистрации обобщена добавлен еше один уровень персадреса- ции и поддерживается направление сообщений непосредственно в файлы. Прежде чем переходить к деталям, приведем мини-словарь терминов, связанных с журнальной регистрацией в пакете B I N D (табл. 16.12). Таблица 16.12. Лексикой покето BIND Термин Что означает канал Место, куда направляются сообщения система Syslog, файл или устройство /dev/null категория Класс сообщений, генерируемых демоном named; например, сообщения о динамических обновлениях или сообщения об ответах на запросы модуль Имя исходного модуля, который сгенерировал сообщение (только в
BIND 9) средство Название средства системы Syslog; зане закреплено собственное средство, ио можно выбрать любое стандартное серьезность Степень тяжести сообщения об ошибке то, что в Syslog называется приоритетом
Конфигурирование журнальной подсистемы осуществляется при помощи инструкции l o g g i n g в файле namcd.cont Сначала определяются каналы — возможные пункты доставки сообщений. Затем различным категориям сообщений назначаются те каналы, куда они будут поступать. При генерации сообщения ему назначается категория, модуль (в BIND 9) н уровень серьезности. После этого оно рассылается по всем каналам, связанным сданными категорией н модулем. В каждом канале имеется фильтр, определяющий, сообщения какого уровня серьезности можно пропускать. Каналы, ведущие в систему Syslog. подвергаются дополнительной фильтрации в соответствии с правилами, установленными в файле /cic/sys- log.conf. Вот обший вид инструкции l o g g i n g : l o g g i n g (
с прем ел ение_ канала ;
определение_ канала
c a t e g o r y ,шя_категсрич
иыя_канала ;
имя_ канала
Глово 16. Системо доменных имен
493
Определение канала может выглядеть немного по-разному в зависимости оттого, ведет ли он к файлу или к системе Syslog. Для каждого канала необходимо выбрать лпбо тип f i l e , либо тип s y s l o g ; совмещать их канал не может. c h a n n e l пня канала { f i l e путь [ v e r s i o n s число_версии | u n l i m i t e d ] I s i z e раамер]; s y s l o g средство
s e v e r i t y серьезность o r y yes I по p r i n r - s e v e r i c y y e s ] n o ; p r i n t - t i m e y e s I n o ;
); Для файлового канала аргумент число_версий сообщает, сколько резервных копий файла нужно хранить. Аргумент размер указывает, какой предельный размер файла допускается (примеры 204 8, 1 0 0 k , 20m, 1 5 g , u n l i m i t e d , d e f a u l t ) . Для каналов системы Syslog задается имя средства, указываемое при регистрации сообщений. Это может быть любое стандартное средство, ио па практике единственный разумный выбор — средства daemon и l o c a 1 0 — l o - c a l ? .
Список средств системы Syslog приводился в параграфе П.
Остальные предложения в определении канала являются необязательными. Аргумент серьезность может принимать следующие значения (в порядке снижения приоритета c r i t i c a l , e r r o r , w a r n i n g , n o t i c e , i n f o и d e b u g к нему может добавляться номер уровня, например s e v e r i t y d e b u g 3). Понимается также значение d y n a m i c , которое соответствует текущему уровню отладки сервера. Различные параметры семейства p r i n t задают или отменяют вывод различных префиксов сообщений. Система Syslog добавляет перед каждым сообщением метку времени и имя узла, ноне уровень серьезности или категорию. В BIND 9 существует также параметр, позволяющий отображать имя исходного файла (модуля, сгенерировавшего сообщение. Параметр p r i n t - t i m e рекомендуется включать только для файловых каналов, поскольку в Syslog произойдет ненужное дублирование информации. В табл. 16.13 перечислены четыре канала, определенные по умолчанию. В большинстве случаев создавать новые каналы не требуется.
Тоблицо 16.13. Стандортнье конолы журнольной регистрации покето BIND Имя капало Назначение d e f a u l t s y s l o g Посылает сообшения уровня info и выше в систему Syslog от имени средства daemon d e f a u l t debug Направляет сообшения в файл named.run: уровень серьезности устанавливается равным dynamic d e f a u l t s r d e r r Направляет сообшения в стандартный канал ошибок демона named с уровнем серьезности i n f o n u l l Отбрасывает все сообщения
494
Чость II. Работа в сетя*
В табл. 16.14 приведен список категорий сообщений, поддерживаемых в B I N D 8 и 9. Категории версии 9 еше не полностью определены. Если в столбце Версия указано "8/9?", это означает, что категория существует в BIND 8, но еще не поддерживается в BIND 9.
Тоблицо 16.14. Котегории сообщений покето BIND Категория Версия Что охватывает d e f a u l t
8/9 Категории, для которых не был явно назначен канал g e n e r a l
9
Неклассифицированные сообщения c o n f i g
8/9 Этап анализа и обработки конфигурационного файла p a r s e r
8 Этап низкоуровневой обработки конфигурационного файла q u e r i e s / c l i e n t
8/9 Короткое сообщение для каждого запроса, принимаемого сервером (!) d n s s e c
9 Сообщения системы DNSSEC l a m e - s e r v e r s
8/97 Сообщения о серверах, которые, как предполагается, обслуживаю зону, нона самом деле это не так s t a t i s t i c s
8/9?
Обшие статистические сообщения ссраерои имен p a n i c
8/9? Фатальные ошибки u p d a t e
8/9 Сообщения о динамических обновлениях ncache
8/9? Сообщения о кэшировании отрицательных ответов x f e r - i n
8/9 Сообщения озонных пересылках, принимаемых сервером Сообщения озонных пересылках, отправляемых сервером Сообщения об операциях с базой данных e v e n t l i b
8 Отладочная информация, поступающая от системы обработки событий p a c k e t
8/9? Копии принимаемых и отправляемых пакетов n o t i f y
8/9 Сообщения об изменении зоны с name
8/9° Сообщения вида "... указывает иа запись CNAME" s e c u r i t y
8/9 Принятые или не принятые запросы
OS
8/9? Ошибки операционной системы i n s i s t
8/9?
Внугренние ошибки m a i n t e n a n c e
8/9? Периодические служебные события l o a d
8/9? Сообщения о загрузке зоны r e s p o n s e - c h e c k s 8/9? Пояснения к неправильно сформированным или неверным ответным пакетам r e s o l v e r
9 Операции преобразования имен, например рекурсивный поиск, выполняемый от имени клиента network
9 Сетевые операции
1
В BIND 8 в категорию d e f a u l t попадают также неклассифицированные сообщения
2
Это может быть как родительская, таки дочерняя зона.
3
Это должен быть единый файловый канал Полный список категорий BIND 8 содержится в файле /include/dns/ confcommon.h. В том же каталоге находится файл log.h со списком модулей.
Глово 16. Системо доменных имен
495
В BIND 9 эти файлы называются lib/dns/include/dns/log.h и bln/named/ln- clude/named/log.h. Стандартный вид инструкции l o g g i n g в BIND 8 таков l o g g i n g { c a t e g o r y d e f a u l t ( d e f a u l t _ s y s l o g ; d e f a u l t _ d e b u g ; 1 ; c a t e g o r y p a n i c J d e f a u l t _ s y s l o g ; d e f a u l t _ _ s t d e r r ; } ; c a t e g o r y e v e n t l i b { d e f a u l t _ d e b u g j c a t e g o r y p a c k e t ( d e f a u l t _ d e b u g ? } ;
}; Вон будет следующим l o g g i n g { c a t e g o r y d e f a u l t { d e f a u l t _ s y s l o g ; d e f a u l t _ d e b u g ; } ;
} ; Нужно просматривать журнальные файлы привнесении существенных изменений в систему BIND; возможно, стоит также повысить уровень отладки. После того как демон named вернется в стабильное состояние, следует переконфигурировать систему так, чтобы регистрировались только важные сообщения. Ниже перечислены наиболее распространенные сообщения.
• Неправильно сконфигурированный сервер. Если подобное сообщение поступает от одной из внутренних зон, значит, в конфигурации системы присутствует ошибка Если же в сообщении говорится о какой-то зоне в Iniernei, то можно не беспокоиться это чья-то чужая ошибка.
• Неправильная отсылка. Это сообщение свидетельствует о непрааильном взаимодействии серверов имен определенной зоны
• Не авторитетен. Подчиненный сервер не может получить авторитетные данные озоне. Возможно, у него хранится неправильная ссылка на главный сервер или же тот не смог загрузить зону
• Отказанная зона. Демон named отказался загружать зонный файл, поскольку тот содержит ошибки.
• Не найдена запись MS. В зонном файле после записи SOA отсутствуют записи NS. Возможно, они действительно отсутствуют либо передними не поставлен знак табуляции или какой-нибудь другой пробельный символ. Во втором случае эти записи не присоединяются к зоне и, следовательно, интерпретируются неправильно.
• Не задано стандартное значение TTL. Желательно задавать стандартное значение TTL посредством директивы 5TTL, расположенной вначале зонного файла. Данная ошибка свидетельствует о том, что такая директива отсутствует. В BIND 8 в подобной ситуации берется значение параметра
мини мольное время жизни записи SO А. В BJND 9 наличие директивы обязательно, в противном случае демон named откажется загружать зониьгй файл.
• Нет корневого сервера имен для данного класса. Демону named не удается найти корневые серверы имен. Следует проверить файл корневых "подсказок' и подключение сервера к Internet.
• Адрес уже используетс.1. Порт, который нужен для работы демона named, занят другим процессом, возможно, другой копией демона. Если демон В BIND 8.2 смысл этого параметра изменился раньше он задавал стандартное значение
TTL для всех записей, теперь — только для отрицательных ответов.
496
Насть II Роботов сетях
отсутствует в списке выполняющихся процессов, то, очевидно, он перед этим аварийно завершил свою работу и оставил открытым управляющий сокет программы tide. Прекрасную таблицу с описанием сообщений об ошибках BIND можно найти по адресу h[Lp://vAvw.acmebw.com/askmrdns/bind-messages.him Уровни отлодки Уровни отладки демона named обозначаются целыми числами от 0 до II Чем выше уровень, тем больше текста содержит выходная информация Уровень 0 выключает отладку. Уровни I и 2 отлично подходят для отладки конфигурационного файла и базы данных. Уровни выше четвертого предназначены для программистов, сопровождающих программный код демона. Отладку можно запустить из командной строки, активизируя демон named с флагом -d. Например, команда
# n»med -d2 запускает демон на уровне отладки 2. По умолчанию отладочная информация записывается в файл named
.ruB, местоположение которого зависит от операционной системы (подробности указаны в параграфе 16-16). Он растет очень быстро, поэтому в процессе отладки будьте внимательны. Если отладку нужно включить вовремя работы демона named, необходимо воспользоваться командой ndc trace, которая увеличивает уровень отладки на единицу. Команда ndc notrace отключает режим отладки. Кроме того, возможно создание канала регистрации сообшеннй, в определение которого входит строка следующего внда: s e v e r i t y d e b u g 3 Она обеспечивает направление всех отладочных сообщений вплоть до уровняв данный канал. Другие директивы в определении канала указывают на то, куда в конечном итоге попадут сообщения. Чем выше уровень серьезности, тем больше информации регистрируется. Просматривая файлы регистрации и отладочные сообщения, можно заметить, как часто делаются ошибки в конфигурации DNS. Малюсенькая точка в конце имени (точнее, ее отсутствие) приводит к угрожающему росту трафика DNS. Теоретически точка нужна в конце каждого полностью определенного имени домена.
Отлодка посредством программы ndc Программа ndc (mdc в BIND 9) — очень удобное средство управления демоном named. Поддерживаемые ею команды перечислены в табл. 16 15 Гс команды, которые создают файлы, помешают их в каталог, обозначенный в файле named.con Г как начальный каталог демона named. Выполнить команду ndc reload — все равно что послать демону named сигнал HUP. Эта команда заставляет демон ново прочитать конфигурационный файл и повторно загрузить зонные файлы. Команду ndc reload юна
удобно применять иа загруженном сервере, когда изменению подвергается только одна зона, а остальные трогать ненужно
Глово 16. Системо доменных имен
497
Таблица 16.15. Полезные отладочные комонды программы ndc Команда Функция __ help Вывод списка доступных команд программы ndc status Отображение текущего статуса выполнения демона named trace Увеличение уровня отладки на единицу по trace Выключение отладки dumpdb Вывод образа базы данных DNS в файл nameddump.db stats Вывод статистической информации в файл named.stats reload Повторная загрузка файла named .conf и зонных файлов reload зона Повторная загрузка только указанной зоны restart Повторный запуск демона named с очисткой кэша querylog Переключение режима трассировки поступающих запросов Команда ndc dumpdb заставляет демон named записать образ своей базы данных в файл nameddump.db. Он будет очень большими будет содержать не только локальные данные, но также данные, накопленные в кэше сервера имен. Не так давно мы провели эту операцию иа основном сервере имен домена colorado.edu, и вышло, что кэш базы данных занял 16 Мбайт, тогда как весь зонный файл — менее 200 Кбайт. Последние версии демоиа named ведут статистику запросов, которую можно получить с помощью команды ndc stats. В ответ на нее демон записывает статистическую информацию в файл named.stats. Ниже показан образец такого файла, взятый с главного сервера домена cs.colorado.edu (перед этим ои непрерывно функционировал в течение х дней. Мы немного сократили вывод, удалив записи, касающиеся устаревших или неиспользуемых типов записей. Кроме того, мы переформатировали нижнюю секцию, которая обычно записывается в одну строку.
+++ S t a t i s t i c s Dump +++ Wed F e b 2 1 5 : 0 7 : 1 8 2 0 0 0 1 8 0 4 6 5 t i m e s i n c e b o o t ( s e e s )
5 2 6 6 9 t i m e s i n c e r e s e t ( s e e s )
0
U n k n o w n q u e r y t y p e s
4 7 5 4 6 0
A q u e r i e s
3
N S q u e r i e s
1 9 4
CNAME q u e r i e s
1 5 6 8 6
SOA q u e r i e s
1 3 8 В 1 6
PTR q u e r i e s
7 6 2 4 4
MX q u e r i e s
1 3 0 9 3 9
TXT q u e r i e s
1
LOC q u e r i e s
1 7 1
SRV q u e r i e s
4 2
AXFR q u e r i e s
1 2 4 5 8 7
ANY q u e r i e s
+*• Name S e r v e r S t a t i s t i c s + +
RR RNXD RFwdR RDupR R F a i l R F E r r
3 2 0 2 5 2 2 3 6 2 0 2 4 9 8 2 6 1 0 1 3 3 5 3 2 0
R O p t s S S y s Q S A n s SFwdQ SDupQ S E r r
R E r r RAXFR RLame
9 0 3 4 2 10339
RQ R I Q RFwdQ



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


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

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


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