Войти
Перенос зоны DNS, также иногда известный как вызывающий тип запроса DNS AXFR, это тип DNS транзакции. Это один из многих механизмов, доступных администраторам для репликации баз данных DNS через набор DNS-серверов.
. Зональная передача использует протокол управления передачей (TCP) для транспорт и принимает форму транзакции клиент-сервер. Клиент, запрашивающий перенос зоны, может быть вторичным сервером, запрашивающим данные от первичного сервера, исторически называемого главным и подчиненным. Реплицируемая часть базы данных - это зона .
Передача зоны состоит из преамбулы, за которой следует фактическая передача данных. Преамбула содержит поиск записи ресурса Начало полномочий (SOA) для «вершины зоны», узла пространства имен DNS, который находится наверху «зоны». Поля этой записи ресурса SOA, в частности «серийный номер», определяют, должна ли вообще происходить фактическая передача данных. Клиент сравнивает серийный номер записи ресурса SOA с серийным номером в последней имеющейся у него копии этой записи ресурса. Если порядковый номер передаваемой записи больше, считается, что данные в зоне «изменились» (некоторым образом), и вторичный сервер переходит к запросу фактической передачи данных зоны. Если серийные номера идентичны, считается, что данные в зоне «не изменились», и клиент может продолжать использовать копию базы данных, которая у него уже есть, если она у него есть.
Фактический процесс передачи данных начинается с того, что клиент отправляет запрос (код операции 0) со специальным типом запроса AXFR (значение 252) через TCP-соединение с сервером. Сервер отвечает серией ответных сообщений, содержащих все записи ресурсов для каждого доменного имени в «зоне». Первый ответ содержит запись ресурса SOA для вершины зоны. Остальные данные следуют в произвольном порядке. Окончание данных сигнализируется сервером, повторяющим ответ, содержащий запись ресурса SOA для вершины зоны.
Некоторые клиенты зональной передачи выполняют поиск преамбулы SOA, используя обычный механизм разрешения запросов DNS своей системы. Эти клиенты не открывают TCP-соединение с сервером, пока не определят, что им необходимо выполнить фактическую передачу данных. Однако, поскольку TCP может использоваться для обычных транзакций DNS, а также для зональной передачи, другие клиенты зональной передачи выполняют преамбулу поиска SOA через то же TCP-соединение, поскольку они затем (могут) выполнять фактическую передачу данных. Эти клиенты открывают TCP-соединение с сервером еще до того, как они выполнят преамбулу.
Предыдущее описывает полную передачу зоны. Инкрементальная передача зоны отличается от полной передачи зоны в следующих отношениях:
Передача зоны полностью инициируется клиентом. Хотя серверы могут отправлять сообщение NOTIFY клиентам (о которых они были проинформированы) всякий раз, когда в данные зоны было внесено изменение, планирование передачи зон полностью находится под контролем клиентов. Клиенты планируют передачи зоны сначала, когда их базы данных пусты, а затем через регулярные интервалы, в соответствии с шаблоном, управляемым значениями в полях «обновить», «повторить» и «истечь» в записи ресурса SOA вершины зоны.
Хотя это стандартизовано, передача полной зоны описывается как один из возможных механизмов репликации базы данных в RFC 1034 и RFC 5936 (добавочная зональная передача описана в RFC 1995 ), зонная передача является наиболее ограниченным из этих механизмов репликации базы данных. Передача зоны работает в терминах ресурсных записей «проводной формат », то есть записей ресурсов, когда они передаются с использованием протокола DNS. Однако схема записей ресурсов формата проводов может не совпадать со схемой базы данных, используемой бэкэндами самих DNS-серверов.
Преамбула передачи зоны полагается на серийный номер и только серийный номер, чтобы определить, изменились ли данные зоны, и, следовательно, требуется ли фактическая передача данных. Для некоторых пакетов DNS-серверов серийные номера записей ресурсов SOA хранятся администраторами вручную. Каждое редактирование базы данных включает в себя два изменения: одно - в изменяемую запись, а другое - в серийный номер зоны. Процесс требует аккуратности: администратор может забыть изменить серийный номер или изменить его некорректно (уменьшить). RFC 1912 (раздел 2.2 Записи SOA) рекомендует использовать значение YYYYMMDDnn в качестве числа (YYYY = год, MM = месяц, DD = день, nn = номер версии). Он не будет переполняться до 4294 года.
В некоторых пакетах DNS-серверов эта проблема решена за счет автоматического построения серийного номера из метки времени последней модификации файла базы данных на диске. Это, например, случай djbdns. Операционная система гарантирует, что отметка времени последнего изменения обновляется всякий раз, когда администратор редактирует файл базы данных, эффективно автоматически обновляя серийный номер и, таким образом, избавляя администраторов от необходимости делать два редактирования (в двух разных местах) для каждого отдельного изменения.
Кроме того, парадигма репликации базы данных, для которой разработана проверка серийного номера (и, собственно, передача зоны), которая включает в себя один центральный DNS-сервер, содержащий основную версию базы данных, а все остальные DNS-серверы просто хранят копий, просто не соответствует таковому у многих современных пакетов DNS-серверов. Современные пакеты DNS-серверов со сложной серверной частью базы данных, такой как серверы SQL и Active Directory, позволяют администраторам вносить обновления в базу данных в нескольких местах (в таких системах используется репликация с несколькими мастерами. ), при этом собственный механизм репликации серверной базы данных обрабатывает репликацию на все другие серверы. Эта парадигма просто не совпадает с парадигмой единственного центрального, монотонно увеличивающегося числа для записи изменений и, таким образом, в значительной степени несовместима с переносом зоны. Современные пакеты DNS-серверов со сложной серверной частью базы данных часто создают серийный номер «прокладки», имитируя существование единого центрального места, где производятся обновления, но это в лучшем случае несовершенно.
К счастью, по этой и нескольким причинам, описанным ниже, DNS-серверы, которые используют такие сложные серверные базы данных, обычно редко используют передачу зоны в качестве механизма репликации базы данных, и обычно вместо этого используют значительно превосходящую распределенную базу данных. механизмы репликации, которые обеспечивают сами серверы.
Сравнение серийных номеров предназначено для использования Арифметики серийных номеров, как определено в RFC 1982. Однако это не было четко указано в RFC 1034, в результате чего не все клиенты выполняют проверку серийного номера в преамбуле одинаково. Некоторые клиенты просто проверяют, что серийный номер, предоставленный сервером, отличается от того, который известен клиенту, или не равен нулю. Другие клиенты проверяют, что серийный номер, предоставленный сервером, находится в заданном диапазоне серийного номера, уже известного клиенту. Тем не менее, другие клиенты по-прежнему выполняют последнюю проверку и дополнительно проверяют, не равен ли серийный номер, предоставленный сервером, нулю.
Первоначально при фактической передаче данных каждый набор записей ресурсов для одного доменного имени и типа передавался в отдельном ответном сообщении от сервера к клиенту. Однако это неэффективно, и некоторое программное обеспечение DNS-серверов реализовало оптимизацию, направленную на то, чтобы механизм сжатия ответов в протоколе DNS уменьшал общие требования к пропускной способности для передачи данных, например:
Некоторые клиенты были написаны с ожиданием только исходного формата ответа и не смогли бы выполнить передачу данных, если бы такая оптимизация использовалась. Таким образом, некоторые пакеты DNS-серверов имеют параметр конфигурации, позволяющий администраторам указывать использование ответов «в формате единого ответа» для тех клиентов, которым это необходимо.
Данные, содержащиеся в зоне DNS, могут быть конфиденциальными с точки зрения операционной безопасности. Это связано с тем, что такая информация, как имена хостов серверов, может стать общедоступной, что может быть использовано для обнаружения информации об организации и даже для обеспечения большей поверхности атаки. В июне 2017 года регистратор, ответственный за российские домены верхнего уровня, случайно включил передачу зон DNS через AXFR, что привело к случайному раскрытию 5,6 миллиона записей.
В 2008 году суд в Северной Дакоте, США, постановил, что выполнение передача зоны в качестве неавторизованного постороннего для получения информации, которая не была общедоступной, представляет собой нарушение закона Северной Дакоты.
