Передача зоны 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 должны правиться администраторами вручную. Каждое изменение базы требует двух правок: собственно записи и серийного номера зоны. Процесс требует аккуратности: администратор может забыть сменить серийный номер либо сменить его неправильно (уменьшить). RFC 1912 (раздел 2.2 SOA records) рекомендует использовать в качестве номера значение вида YYYYMMDDnn (YYYY=год, MM=месяц, DD=день, nn=версия изменения за день). Такой формат даёт возможность использовать номер до 4294 года и делать 100 изменений в день (nn от 00 до 99), давая возможность контролировать дату последнего изменения.

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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

Ссылки
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.