Репликация и зонные передачи

Теоретическая часть

DNS - Domain Name System (система доменных имен), т.е. система именования компьютеров и сетевых служб, организованных в виде иерархии доменов.

Большинство пользователей предпочитает использовать понятное имя, такое как mx.bmstu.ru, для поиска компьютера, являющегося почтовым сервером или веб-сервером сети. Служба DNS обеспечивает сопоставление понятного имени компьютера или службы с его IP адресом. Данная функция службы DNS называется прямым просмотром.

Следующий рисунок иллюстрирует использование DNS, т.е. обнаружение IP-адреса компьютера по его имени.

В этом примере клиентский компьютер запрашивает у сервера IP-адрес компьютера с доменным именем DNS host-a.mx.bmstu.ru. Поскольку сервер может ответить на запрос с помощью своей локальной базы данных, он возвращает ответ, содержащий запрашиваемую информацию, т.е. запись ресурса узла (A), содержащую IP-адрес, соответствующий имени host-a.mx.bmstu.ru.

Порядок разрешения имени

При разрешении имени компьютер не сразу отправляет запрос к DNS серверу. Перед этим он производит ряд действий, направленных на уменьшение загрузки DNS сервера. Первоначально компьютер просматривает нет ли соответствующей записи в его кэше, или файле hosts.

Таким образом выделяются следующие этапы разрешения имени:

1. проверка локального кэша, где хранятся результаты предыдущих запросов;
2. проверка, не является ли искомый компьютер данным (локальный запрос);
3. просмотр файла Hosts;
4. непосредственное обращение к DNS серверу.
   Общие сведения о различии между зонами и доменами

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

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

На рисунке 1 показан домен bmstu.ru. Когда домен bmstu.ru создавался на одном сервере, он имел конфигурацию единственной зоны для всего пространства имен DNS корпорации Майкрософт. Однако при необходимости использования поддоменов домена bmstu.ru эти поддомены могли включаться в зону или делегироваться в другие зоны.

В этом примере домен example.bmstu.ru демонстрирует новый поддомен — домен example.bmstu.ru — делегированный из зоны bmstu.ru и управляемый в собственной зоне. Однако зона bmstu.ru должна содержать несколько записей ресурсов, обеспечивающих сведения о делегировании, со ссылками на DNS-серверы, полномочные для делегированного поддомена example.bmstu.ru.

Если зона bmstu.ru не использует делегирование поддомена, любые данные поддомена остаются частью зоны bmstu.ru. Например, поддомен dev.bmstu.ru не делегируется, а управляется зоной bmstu.ru.

Рис.1

Таким образом, DNS является распределенной системой, построенной по иерархическому принципу. Это связано с тем, что один компьютер не может эффективно хранить и обрабатывать такие большие объемы данных.

Обратный просмотр

В большинстве операций просмотра DNS-клиенты обычно выполняют прямой просмотр, т.е. поиск, основанный на имени DNS другого компьютера, сохраненного в записи ресурса адреса (A). В этом типе запроса в качестве данных для ответа на запрос ожидается IP-адрес.

DNS также обеспечивает возможность обратного просмотра, в котором клиенты используют известный IP-адрес для поиска имени компьютера по этому адресу. Обратный просмотр фактически является формой вопроса типа «Можете ли вы выдать мне имя DNS компьютера, который использует IP-адрес 192.168.1.20?»

Система DNS не разрабатывалась изначально для поддержки запросов этого типа. Одной из проблем при поддержке запросов обратного просмотра является различие в способах организации и индексации пространства имен DNS и способов назначения IP-адресов. Если бы единственным способом ответа на предыдущий вопрос был поиск во всех доменах пространства имен DNS, то для обработки обратного запроса потребовалось бы слишком много времени и такой запрос оказался бы бесполезным.

Чтобы разрешить эту проблему, в стандартах DNS был определен и зарезервирован специальный домен в пространстве имен DNS, in-addr.arpa, обеспечивающий практичный и надежный способ выполнения обратных запросов. Чтобы создать обратное пространство имен, поддомены в домене in-addr.arpa формируются с помощью обратного упорядочения чисел в точечно-десятичной нотации IP-адресов.

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

По этой причине порядок октетов IP-адреса должен быть обращен при построении дерева домена in-addr.arpa. В такое компоновке администрирование нижних частей дерева DNS in-addr.arpa может отдаваться организациям, которым назначается ограниченный набор IP-адресов в классах адресов Интернета. Например, для сети 192.168.1 будет использован домен 1.168.192.in-addr.arpa.

Для дерева домена in-addr.arpa, встроенного в DNS, требуется определение дополнительного типа записей ресурсов — запись ресурса указателя (PTR). Такая запись ресурса используется для сопоставления в зоне обратного просмотра, обычно соответствующего записи ресурса именованного узла (A) для имени DNS компьютера в зоне прямого просмотра.

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

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

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

• IP-адрес добавлен, удален или изменен в конфигурации свойств TCP/IP для любого из установленных сетевых подключений.
• Изменена или обновлена аренда IP-адреса на DHCP-сервере для любого из установленных сетевых подключений. Например, когда запускается компьютер или используется команда ipconfig /renew.
• С помощью команды ipconfig /registerdns вручную принудительно обновляется регистрация имени клиента в DNS.
• Компьютер запускается при его включении.

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

Репликация и зонные передачи

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

Когда в сеть добавляется новый DNS-сервер, для которого задается конфигурация нового дополнительного сервера существующей зоны, он выполняет полную начальную передачу зоны (AXFR) для получения и репликации полной копии записей ресурсов зоны. Для большинства ранних реализаций DNS-сервера тот же способ полной передачи зоны используется, когда зоне требуется обновление после внесения изменений в зону. В операционной системе Windows 2000 Server служба DNS поддерживает добавочные зонные передачи (IXFR), представляющие способ передач для зон DNS только непосредственно изменений.

Зонная передача

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

• Истек интервал обновления зоны.
• Дополнительный сервер получил уведомление об изменениях зоны от главного сервера.
• Служба DNS-сервер запускается на дополнительном сервере зоны.
• С консоли DNS на дополнительном сервере зоны вручную инициируется передача с главного сервера зоны.

Зонные передачи всегда инициируются на дополнительном сервере зоны (slave) и отправляются на указанные в конфигурации главные серверы (master), служащие источниками для зоны. Главным сервером может быть любой DNS-сервер, загружающие зону, например, основной сервер зоны или другой дополнительный сервер. Когда главный сервер принимает запрос для зоны, он может в ответ выполнить частичную (IXFR) или полную (AXFR) передачу зоны на дополнительный сервер.

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

На рисунке 2 показана последовательность действий для запрашивающего дополнительного сервера зоны — целевого сервера — и сервера-источника, т.е. другого DNS-сервера, на котором находится зона.

Рис.2

1. Во время настройки новой конфигурации целевой сервер посылает начальный запрос на передачу «всей зоны» (AXFR) главному DNS-серверу, являющемуся источником зоны в текущей конфигурации.
2. Главный сервер (источник) отвечает и полностью передает зону на целевой дополнительный сервер (получатель).

Зона доставляется на дополнительный сервер, запросивший передачу, с версией, установленной с помощью поля Серийный номер в свойствах начальной записи зоны. Начальная запись зоны (SOA) содержит также установленное значение интервала обновления в секундах (по умолчанию 900 секунд или 15 минут), указывающее, когда целевой сервер должен следующий раз запросить обновление зоны с сервера-источника.

1. По истечении интервала обновления целевой сервер с помощью начальной записи зоны (SOA) запрашивает обновление зоны с сервера-источника.
2. Сервер-источник отвечает на запрос для начальной записи зоны.

Ответ содержит текущее значение серийного номера зоны на сервере-источнике.

1. Целевой сервер проверяет серийный номер начальной записи зоны в ответе и определяет, как следует обновлять зону.

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

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

1. Если целевой сервер заключает, что зона изменилась, он отправляет на исходный сервер запрос IXFR, содержащий текущее локальное значение серийного номера в начальной записи зоны.
2. Сервер-источник в ответ выполняет либо добавочную, либо полную передачу зоны.

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

Если сервер-источник не поддерживает добавочные передачи или не имеет сохраненной истории изменений зоны, он может в ответ выполнить полную зонную передачу (AXFR).

Кэширующий сервер DNS

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

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

Файлы, относящиеся к DNS

Следующие файлы используются при работе и настройке серверов и клиентов DNS под Windows 2000. Такие файлы можно найти в папке %SystemRoot%\System32\DNS.

Boot - файл конфигурации загрузки BIND. Этот файл не создается консолью DNS. Однако в качестве дополнительной конфигурации службы DNS-сервер он может быть скопирован с другого сервера DNS, на котором выполняется реализация BIND (Berkeley Internet Name Domain) сервера DNS. Для использования этого файла со службой DNS-сервера необходимо выбрать в свойствах сервера параметр Load from file.

Cache.dns - используется для предварительной загрузки записей ресурсов в кэш имен серверов DNS.

Root.dns - файл корневой зоны. Этот файл может появиться на компьютере, на котором выполняется DNS-сервер Windows 2000, если он имеет конфигурацию корневого сервера сети.

имяЗоны.dns - используется, когда на сервере добавляется и настраивается стандартная зона (первичная или вторичная).

Hosts – статический файл с записями соответствий доменных имен компьютеров и их IP адресов.