Обновление файлов зон
Категория: Система доменных имен | Автор: admin | 30-04-2010, 03:29 | Просмотров: 4285

Когда в домен вносится изменение (например, добавляется или удаляется компьютер), следует откорректировать файлы данных на главном сервере Кроме того, надлежит увеличить порядковый номер в записи SOA для этой зоны и выполнить команду ndc reload, которая просигнализирует демону named о необходимости принять изменения. Можно просто уничтожить и перезапустить демон (команда ndc restart), но это вызовет уничтожение кэшированных данных, полученных из других доменов.

В ранних версиях BIND для управления демоном named применялись сигналы и команда kill, но когда у разработчиков перестало хватать сигналов, появилась команда ndc, которая исправила ситуацию. Скорее всего, в будущем сигналы вообще перестанут поддерживаться (за исключением сигнала HUP вызывающего повторное чтение конфигурационного файла, и сигнала TERM приводящего к выгрузке демона), поэтому рекомендуем пользоваться командой ndc.

Обновленные зонные данные будут переданы подчиненным серверам немедленно, поскольку параметр notify включен по умолчанию. Если же по какой-то причине он был отключен, подчиненным серверам придется дожидаться, пока истечет период обновления, установленный в записи SOA зоны (обычно от одного до шести часов). В случае, когда необходима более срочная корректировка, можно выполнить на подчиненном сервере команду ndc reload, которая заставит его связаться с главным сервером, убедиться в том, что данные изменены, и запросить пересылку зонных данных.

При изменении имени или IP-адреса компьютера не забывайте модифицировать зоны как прямого, так и обратного преобразования. Если забыть о файлах, в которых хранятся данные для обратного преобразования, это приведет к появлению скрытых ошибок: некоторые команды будут работать, а некоторые — нет.

Если изменить файлы данных, но не обновить порядковый номер в записи SOA, то изменения вступят в силу только на главном сервере (после перезагрузки), но не на подчиненных.

Не следует редактировать файлы данных, относящиеся к подчиненным серверам. Эти файлы ведет сам демон named; системные администраторы не должны вмешиваться в его работу. Лучше всего только просматривать файлы данных, не делая в них никаких изменений. По этим файлам часто можно обнаружить скрытые ошибки конфигурации. Например, досадный пропуск точки, который можно запросто не заметить в файлах конфигурации главного сервера, может привести к появлению в файле данных подчиненного сервера явно ложного элемента наподобие

foo.cs.colorado.edu.cs.colorado.edu

 

Документ RFC2136 разрешает производить зонные изменения через библиотеку API-функций. Эта возможность называется динамическим обновлением; оно необходимо для протоколов автоматического конфигурирования, таких как DHCP. О том, как работает данный механизм, речь пойдет чуть ниже.

 

Зонные пересылки

 

Серверы DNS синхронизируются посредством механизма зонных пересылок. В исходной спецификации DNS (и в BIND 4) требовалось, чтобы все данные, относящиеся к той или иной зоне, пересылались одновременно. Инкрементные обновления были определены в документе RFC 1995 и реализованы в BIND 8.2.

Подчиненный сервер, который хочет обновить свои данные, запрашивает зонную пересылку с главного сервера и создает резервную копию данных на диске. Если данные на главном сервере не изменились, что можно определить путем сравнения порядковых номеров (не самих данных), корректировка не производится и резервные копии файлов практически остаются без изменений (лишь время их модификации устанавливается равным текущему времени).

Зонные пересылки осуществляются по протоколу TCP через порт 53. Соответствующее событие регистрируется системой Syslog с пометкой "named-xfer". Организация IETF определила, что инкрементные обновления могут производиться либо по протоколу TCP, либо UDP, но в BIND реализован лишь первый вариант.

Во время зонной пересылки и передающий, и принимающий серверы остаются доступными для запросов. Подчиненный сервер начинает использовать новые данные только после завершения всей операции. В BIND 8 пересылка осуществляется путем вызова отдельной программы named-xfer, а в BIND 9 демон named управляет данной операцией напрямую. Как следствие, параметр named-xfer, определявший путь к одноименной программе, перестал поддерживаться в конфигурационном файле BIND 9.

Если зона очень велика (например, "com") или обновляется динамически (см. следующий раздел), объем изменений обычно мал в сравнении с размером всей зоны. В этом случае используются инкрементные обновления, при которых пересылаются только изменения (в том случае, когда изменения превышают размер зоны, производится обычная зонная пересылка). Этот механизм напоминает программу patch: старая база данных сравнивается и синхронизируется с новой.

В BIND 8 для включения инкрементных зонных пересылок следует указать демону named на необходимость ведения журнала транзакций (это делается в глобальной секции options), а затем установить соответствующий атрибут в инструкции server любого сервера, которому нужны такие пересылки. Конфигурационные строки выглядят так:

 

maintain-ixfr-base true;       # в секции options

support-ixfr true;             # в инструкции server

 

 

Если требуется изменить стандартные имена журнала транзакций и временного файла, используемого при инкрементных пересылках, разместите в инструкции zone следующие директивы:

 

ixfr-base "имя_файла";         # в инструкции zone

ixfr-tmp-file "имя_файла";     # в инструкции zone

 

 

В BIND 9 инкрементные пересылки поддерживаются по умолчанию для любой зоны, сконфигурированной на прием динамических обновлений, а демон named самостоятельно ведет журнал транзакций. В инструкции server теперь поддерживаются две отдельные директивы: provide-ixfr и request-ixfr. Первая включает или отключает механизм инкрементных пересылок для зон, в которых сервер является главным. Вторая делает то же самое для тех зон, где сервер является подчиненным.

 

provide-ixfr yes;           # в инструкции server

request-ixfr yes;           # в инструкции server

 

 

Пакет BIND не работает с зонами, которые одновременно могут обновляться динамически и редактироваться вручную. Сервер BIND 9 может инициировать инкрементную пересылку в результате динамического обновления или другой поступившей пересылки, но не тогда, когда изменения вызваны редактированием зонных файлов. Вероятно, эта возможность появится в следующих версиях пакета.

Было проделано много работы, чтобы в случае краха сервера во время инкрементной пересылки зонные данные не превращались в мусор. Запрос на инкрементную пересылку к серверу, который не поддерживает данный механизм, будет автоматически преобразован в обычный запрос на обновление

 

Динамические обновления

 

Система DNS основана на предпосылке, что соответствия между именам и адресами относительно стабильны и меняются нечасто. Но это правиле постоянно нарушается, если в организации используется протокол DHCP и при подключении к сети компьютеру динамически назначается IP-адрес Имеется два классических решения: добавить обобщенные записи в базу данных DNS или непрерывно редактировать DNS-файлы. В большинстве случаев ни одно из решений не является удовлетворительным.

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

 

dhcp-hostl.domain.        IN   A     192.168.0.1

dhcp-host2.domain.        IN   A     192.168.0.2

 

 

Это простое решение, но оно означает, что указанные имена постоянно связаны с данными IP-адресами, а компьютер, получающий новый адрес, меняет имя. В такой среде трудно соблюдать требования безопасности, да и просто регистрироваться в системе под определенным именем.

Механизм динамических обновлений, появившийся в последних версиях BIND, предлагает альтернативное решение. Он позволяет демону DHCP уведомлять сервер BIND о сделанных адресных назначениях, обновляя таким образом содержимое базы данных DNS "на лету". Имеется также интерфейс командной строки, дающий возможность выполнять динамические обновления вручную.

Посредством данного механизма можно добавлять, удалять и модифицировать записи о ресурсах. Глубина обновлений — зона. Немного страшно разрешать динамические обновления всей базы данных DNS, поэтому многие организации создают поддомен (скажем, dhcp.организация) и осуществляют динамические обновления только в его пределах.

Динамические обновления зоны разрешаются в файле named.conf посредством директивы allow-update. После того как зона была динамически обновлена, ее нельзя редактировать вручную — нужно сначала остановить сервер BIND, чтобы текущая копия базы данных была записана на диск. Затем можно отредактировать зонный файл и перезапустить демон named. Естественно, исходное форматирование зонного файла будет разрушено (он будет выглядеть как файл, который ведется демоном named на подчиненных серверах).

Инкрементные зонные пересылки по умолчанию поддерживаются для зон, в которых используются динамические обновления. Но через механизм инкрементных пересылок не распространяются изменения зоны, осуществляемые посредством ручного редактирования главного файла, даже если остановить демон named, отредактировать зонный файл и затем перезапустить демон.


 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page