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

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

Зонная передача использует протокол управления передачей (TCP) для транспортировки, ^{[1] [2]} и принимает форму клиент-серверной транзакции. Клиент, запрашивающий зонную передачу, может быть вторичным сервером, запрашивающим данные с первичного сервера . ^[3] Часть базы данных, которая реплицируется, является зоной .

Передача зоны состоит из преамбулы, за которой следует фактическая передача данных. Преамбула включает поиск записи ресурса Start of Authority (SOA) для «вершины зоны», узла пространства имен DNS, который находится наверху «зоны». Поля этой записи ресурса SOA, в частности «серийный номер», определяют, должна ли вообще происходить фактическая передача данных. Клиент сравнивает серийный номер записи ресурса SOA с серийным номером в последней копии этой записи ресурса, которая у него есть. Если серийный номер передаваемой записи больше, данные в зоне считаются «измененными» (каким-то образом), и вторичный сервер переходит к запросу фактической передачи данных зоны. Если серийные номера идентичны, данные в зоне считаются не «измененными», и клиент может продолжать использовать копию базы данных, которая у него уже есть, если она у него есть.

Фактический процесс передачи данных начинается с того, что клиент отправляет запрос (код операции 0) со специальным типом запроса AXFR (значение 252) по TCP-соединению на сервер. Хотя DNS технически поддерживает AXFR по протоколу пользовательских датаграмм (UDP), это считается неприемлемым из-за риска потери или подделки пакетов. ^{[2] [1]} Сервер отвечает серией ответных сообщений, содержащих все записи ресурсов для каждого доменного имени в «зоне». Первый ответ содержит запись ресурса SOA для вершины зоны. Остальные данные следуют в произвольном порядке. Окончание данных сигнализируется повторением сервером ответа, содержащего запись ресурса SOA для вершины зоны.

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

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

• Клиент использует специальный QTYPE IXFR (значение 251) вместо AXFR QTYPE.
• Клиент отправляет запись ресурса SOA для вершины зоны, которая у него в данный момент имеется (если таковая имеется), в сообщении IXFR, давая серверу знать, какую версию «зоны» он считает текущей.
• Хотя сервер может ответить обычным способом AXFR с полными данными для зоны, он также может вместо этого ответить "инкрементальной" передачей данных. Последняя включает список изменений в данных зоны в порядке серийных номеров зон между версией зоны, которую клиент сообщил серверу как имеющую, и версией зоны, которая является текущей на сервере. Изменения включают два списка, один из записей ресурсов, которые удаляются, и один из записей ресурсов, которые вставляются. (Изменение записи ресурса представлено как удаление, за которым следует вставка.)

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

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

В этом разделе есть несколько проблем. Помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Для проверки этого раздела необходимы дополнительные цитаты .Пожалуйста, помогите улучшить эту статью , добавив ссылки на надежные источники в этом разделе. Материалы без ссылок могут быть оспорены и удалены. ( Июль 2021 г. )( Узнайте, как и когда удалить это сообщение ) Этот раздел написан в форме личных размышлений, личного эссе или аргументационного эссе , в котором излагаются личные чувства редактора Википедии или представляются оригинальные аргументы по теме.Пожалуйста, помогите улучшить его, переписав в энциклопедическом стиле . ( Июль 2021 г. )( Узнайте, как и когда удалить это сообщение ) ( Узнайте, как и когда удалить это сообщение )

Вводная часть передачи зоны опирается на серийный номер и только на серийный номер, чтобы определить, изменились ли данные зоны, и, таким образом, требуется ли фактическая передача данных. Для некоторых пакетов 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 снизить общие требования к пропускной способности передачи данных, такие как:

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

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

Данные, содержащиеся в зоне DNS, могут быть чувствительными с точки зрения эксплуатационной безопасности. Это связано с тем, что такая информация, как имена хостов серверов, может стать общедоступной, что может быть использовано для обнаружения информации об организации и даже обеспечить большую поверхность атаки . В июне 2017 года регистратор, ответственный за российские домены верхнего уровня, случайно включил передачу зон DNS через AXFR, что привело к случайному раскрытию 5,6 миллионов записей. ^[4]

В 2008 году суд в Северной Дакоте, США, постановил, что осуществление зонного перехода в качестве несанкционированного стороннего лица с целью получения информации, которая не является общедоступной, является нарушением закона Северной Дакоты. ^[5]

• Список типов записей DNS

• «Как работает протокол AXFR». Интернет-публикация, DJ Bernstein . Получено 15 февраля 2005 г.
• "Понимание зон и передачи зон". Документация по продукту Microsoft Windows Server 2003. 8 октября 2009 г. Получено 27.11.2011 .
• «Как работает поддержка DNS для Active Directory». Документация по продукту Microsoft Windows Server 2003. Получено 27.11.2011 .
• "Репликация зоны DNS в Active Directory". Документация по продукту Microsoft Windows Server 2003. 8 октября 2009 г. Получено 27.11.2011 .
• МакКлур, Стюарт; Скамбрей, Джоэл; Курц, Джордж (2009). Взлом раскрыт: секреты и решения сетевой безопасности (6-е изд.). McGraw-Hill. ISBN 978-0-07-161374-3.

• Передача зон DNS CAPEC-291
• CVE-1999-0532 DNS-сервер разрешает передачу зон.
• Конфигурация CWE-16
• CWE-276 Неверные разрешения по умолчанию

• RFC 5936 DNS Zone Transfer Protocol (определяет AXFR, обновляет RFC 1034 Domain Names - Concepts and Facilities и RFC 1035 Domain Names - Implementation and Specification)
• RFC 1995 Инкрементная передача зоны в DNS
• RFC 1996 Механизм оперативного уведомления об изменениях зоны (DNS NOTIFY)
• draft-ietf-dnsext-axfr-clarify Протокол передачи зон DNS (AXFR) Интернет-проект