Передача зоны DNS, AXFR — вид RFC 1995). Имела очень широкое распространение, однако в современных серверах DNS вытесняется другими механизмами репликации.

Принцип действия

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

Эта транзакция состоит из преамбулы и собственно передачи данных. В ходе преамбулы происходит просмотр записи SOA (авторитетного источника) в начале зоны (англ. zone apex) — верхнем узле пространства имён этой зоны. Поля этой записи SOA, в частности, серийный номер, определяют, нужна ли передача зоны вообще. Клиент сравнивает серийный номер полученной записи SOA и уже имеющейся. Если номер новой записи выше, значит содержимое зоны изменилось к какой-либо степени, и клиент запрашивает фактическую передачу зоны. Если же серийные номера одинаковы, то содержимое зоны считается неизменным, и клиент может продолжать использовать уже имеющуюся копию данных.

В начале фактической передачи данных клиент отправляет запрос (код операции 0) специального типа AXFR (QTYPE AXFR = 252) через соединение TCP. Сервер в ответ последовательно отправляет сообщения со всеми ресурсными записями зоны. Первое сообщение содержит запись SOA начала зоны. Остальные сообщения не упорядочиваются. Сигналом конца передачи является повторная отправка записи SOA.

Некоторые клиенты выполняют просмотр SOA посредством стандартного механизма разрешения имён. Они не устанавливают TCP-соединение с сервером до тех пор, пока не определят необходимость фактической передачи. Тем не менее, поскольку TCP можно применять и для обычных транзакций DNS, и для передачи зоны, другие клиенты проводят разрешение записи SOA в преамбуле поверх того же самого соединения, что они возможно будут использовать для фактической передачи. Таки клиенты устанавливают TCP-соединение с сервера ещё до начала преамбулы.

Выше изложены принципы полной передачи. Инкрементальная передача зоны отличается следующим:

• Вместо запроса типа AXFR выполняется IXFR (код 251).
• Клиент отправляет имеющуюся у него запись SOA в сообщении IXFR, уведомляя сервер о текущей, по его сведениям, версии зоны.
• Сервер может ответить полной передачей способом AXFR либо инкрементальной передачей. В последнем случае будет передан список промежуточных изменений данных зоны, упорядоченный по серийным номерам зоны. Изменения будут представлены двумя списками: удалённых и добавленных записей. Изменение содержимого записи оформляется как удаление и вставка.

Передачу зоны инициирует только клиент. Сервер может отправлять сообщение NOTIFY известным ему клиентам, когда в зоне произошли изменения, однако планирование передачи находится целиком в ведении клиента. Передача зоны может быть запущена клиентом, если его базы данных пусты, и далее по расписанию, определяемому на основе полей refresh, retry и expire в записи SOA начала зоны.

Ограничения

Хотя полная передача стандартизована и описана как один из возможных механизмов репликации в бэк-эндом самих серверов DNS.

Функциональные проблемы

Изменение серийных номеров

Преамбула передачи зоны опирается только на серийный номер, чтобы определить, изменились ли данные зоны, и нужна ли фактическая передача. В некоторых серверах DNS серийные номера SOA должны правиться администраторами вручную. Каждое изменение базы требует двух правок: собственно записи и серийного номера зоны. Это процесс трудоёмкий и ненадёжный; администратор может забыть сменить серийный номер либо сменить его неправильно (например, уменьшить или чрезмерно увеличить).

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

Кроме того, устарела сама парадигма репликации базы данных, основанная на проверке серийных номеров, когда центральный DNS-сервер хранит мастер-копию, а остальные серверы лишь её дублируют. Современные серверы со сложными бэк-эндами, такими как SQL и Active Directory, позволяют администраторам править несколько участков одновременно (системы с репликацией multi-master), где нижележащая база данных самостоятельно обрабатывает репликацию на другие серверы. Такая модель не соответствует старой парадигме единой централизованной монотонно возрастающей записи изменений, а значит в общем виде не совместима с передачей зоны. Современные серверы DNS со сложными бэк-эндами на базах данных зачастую создают «мнимый» серийный номер, симулируя наличие централизованного источника обновлений, однако это по меньшей мере несовершенство.

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

Сравнение серийных номеров

Сравнение серийных номеров предполагает использование арифметики серийных номеров (например, во избежание RFC 1034, и в результате клиенты сравнивают номера в преамбуле по-разному. Одни лишь удостоверяются, что полученный номер отличается от имеющегося или ненулевой. Другие проверяют, что полученный номер находится в заданном интервале от имеющегося. Третьи кроме этого также делают проверку на ноль.

Множественные ресурсные записи

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

• выполняли «обработку дополнительных секций» и включали в ответ связанные (англ. glue) ресурсные записи, такие как NS, SRV или MX;
• группировали записи по доменному имени и отправляли, если позволял размер пакета, одним сообщением.

Некоторые клиенты ожидали только первоначальный формат ответа и не могли принять данные, оптимизированные таким образом. С учётом этого отдельные серверы DNS имели настройки для отправки «ответов одиночного формата» таким клиентам.

Раскрытие данных

Информация, содержащаяся в зоне DNS может считаться конфиденциальной с точки зрения операционной безопасности. Например, ресурсные записи могут содержать сведения о роли серверов или отпечатки ключей SSH (RFC 4255).

В 2008 г. суд Северной Дакоты, США, постановил, что несанкционированная передача приватной зоны, инициированная посторонним, является нарушением закона штата.

См. также

• Ресурсные записи DNS

Документы RFC по теме

• RFC 1034 Domain Names — Concepts and Facilities. (определение AXFR)
• RFC 1995 Incremental Zone Transfer in DNS
• RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• draft-ietf-dnsext-axfr-clarify DNS Zone Transfer Protocol (AXFR) (рабочий документ)

Ссылки

• How the AXFR protocol works. Internet publication, D. J. Bernstein. Архивировано из первоисточника 26 января 2013. Проверено 15 февраля 2005.
• Understanding zones and zone transfer. Microsoft Windows Server 2003 product documentation. Архивировано из первоисточника 26 января 2013. Проверено 27 ноября 2011.
• How DNS Support for Active Directory Works. Microsoft Windows Server 2003 product documentation. Архивировано из первоисточника 26 января 2013. Проверено 27 ноября 2011.
• DNS zone replication in Active Directory. Microsoft Windows Server 2003 product documentation. Архивировано из первоисточника 26 января 2013. Проверено 27 ноября 2011.