Передача зоны DNS

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Передача зоны DNS, AXFR — вид транзакции DNS. Является одним из механизмов репликации баз DNS между серверами. Существует два вида передачи зоны: полная (AXFRRFC 1035) и инкрементальная (IXFRRFC 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 начала зоны.

Ограничения[править | править исходный текст]

Хотя полная передача стандартизована и описана как один из возможных механизмов репликации в RFC 1034 (инкрементальная — в RFC 1995), передача зоны — наименее функциональный способ репликации баз. Передача записей «неинтеллектуальна», т. е. использует тот же самый протокол, что и обычное разрешение имён DNS. Она не учитывает нижележащую схему базы данных, используемой бэк-эндом самих серверов DNS.

Функциональные проблемы[править | править исходный текст]

Изменение серийных номеров[править | править исходный текст]

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

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

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

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

Сравнение серийных номеров[править | править исходный текст]

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

Множественные ресурсные записи[править | править исходный текст]

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

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

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

Раскрытие данных[править | править исходный текст]

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

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

См. также[править | править исходный текст]

Документы RFC по теме[править | править исходный текст]

Ссылки[править | править исходный текст]