Перенос DNS-зоны

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

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

Операция

Передача зоны состоит из преамбулы, за которой следует собственно передача данных. Преамбула включает поиск записи ресурса начала полномочий (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) вместо QTYPE AXFR.
Клиент отправляет запись ресурса SOA для вершины зоны, которая у него есть в данный момент, если таковая имеется, в сообщении IXFR, сообщая серверу, какую версию «зоны» он считает текущей.
Хотя сервер может ответить обычным способом AXFR, передав полные данные для зоны, он также может вместо этого ответить «добавочной» передачей данных. Последний включает список изменений данных зоны в порядке серийных номеров зон между версией зоны, о наличии которой клиент сообщил серверу, и версией зоны, которая является текущей на сервере. Изменения состоят из двух списков: одного из удаленных записей ресурсов, а другого — вставленных записей ресурсов. (Модификация записи ресурса представляет собой удаление с последующей вставкой.)

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

Ограничения

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

Эксплуатационные проблемы

Изменение серийного номера

Преамбула передачи зоны зависит от серийного номера и только от серийного номера, чтобы определить, изменились ли данные зоны и, следовательно, требуется ли фактическая передача данных. Для некоторых пакетов DNS-серверов серийные номера записей ресурсов SOA сохраняются администраторами вручную. Каждое редактирование базы данных включает внесение двух изменений: одно в изменяемую запись, а другое в серийный номер зоны. Процесс требует аккуратности: администратор может забыть изменить серийный номер или изменить его неправильно (уменьшить). RFC 1912 (раздел 2.2 записи SOA) рекомендует использовать в качестве числа значение YYYYMMDDnn (ГГГГ=год, ММ=месяц, ДД=день, 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

Ссылки

^ Перейти обратно: ^а ^б «Доменные имена – реализация и спецификация» . IETF . Ноябрь 1987 года.
^ Перейти обратно: ^а ^б Дикинсон, Джон; Дикинсон, Сара; Беллис, Рэй; Мэнкин, Эллисон; Весселс, Дуэйн (март 2016 г.). «Транспорт DNS через TCP — требования к реализации» . IETF .
^ Фудзивара, Кадзунори; Салливан, Эндрю; Хоффман, Пол (2019). «Терминология DNS» . www.tools.ietf.org . дои : 10.17487/RFC8499 . Проверено 21 июня 2020 г.
^ «Неправильная конфигурация привязки открывает доступ к Интернету полный список российских доменов верхнего уровня» . Блог SecurityTrails . 14 марта 2018 г. Проверено 10 апреля 2018 г.
^ «Антиспамер оштрафован за доступ к DNS-записям частной сети» . Х. 18 января 2008 г.

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

Внешние ссылки

Информация о стандартах безопасности

Связанный запрос на комментарии

Протокол передачи зоны DNS RFC 5936 (определяет AXFR, обновляет доменные имена RFC 1034 — концепции и возможности и доменные имена RFC 1035 — реализация и спецификация)
RFC 1995: добавочная передача зоны в DNS
RFC 1996. Механизм оперативного уведомления об изменении зоны (DNS NOTIFY).
протокола передачи зоны DNS (AXFR) Draft-ietf-dnsext-axfr-clarify Интернет-проект

[:0-1] Перейти обратно: ^а ^б «Доменные имена – реализация и спецификация» . IETF . Ноябрь 1987 года.

[:1-2] Перейти обратно: ^а ^б Дикинсон, Джон; Дикинсон, Сара; Беллис, Рэй; Мэнкин, Эллисон; Весселс, Дуэйн (март 2016 г.). «Транспорт DNS через TCP — требования к реализации» . IETF .

[3] Фудзивара, Кадзунори; Салливан, Эндрю; Хоффман, Пол (2019). «Терминология DNS» . www.tools.ietf.org . дои : 10.17487/RFC8499 . Проверено 21 июня 2020 г.

[4] «Неправильная конфигурация привязки открывает доступ к Интернету полный список российских доменов верхнего уровня» . Блог SecurityTrails . 14 марта 2018 г. Проверено 10 апреля 2018 г.

[5] «Антиспамер оштрафован за доступ к DNS-записям частной сети» . Х. 18 января 2008 г.

[1]

[2]

[3]

[4]

[5]