Транзакции DNS

Ограничение рекурсивных запросов (специальный случай DNS Query/Response)

Авторитетный name-сервер обеспечивает сервис разрешения имен для клиента, исходя из своих собственных данных. Следовательно, конфигурирование авторитетного name-сервера должно быть сделано таким образом, чтобы он мог принимать запросы от любых хостов. Обеспечение безопасности авторитетного name-сервера состоит в выключении возможности рекурсивного запроса, чтобы этот сервер не испортил свой кэш, запрашивая другие (возможно, скомпрометированные) name-серверы. Локальный рекурсивный name-сервер может быть сконфигурирован таким образом, чтобы принимать запросы только от внутренних хостов, что защитит его от DoS-атак, а также от порчи кэша. Однако возможны ситуации, когда экономически нежелательно иметь выделенные серверы для авторитетного сервиса и сервиса разрешения имен, и рекурсивный name-сервер должен выполняться как авторитетный сервер для одной или более зон. В такой ситуации возможны следующие стратегии с использованием BIND 9.х name-сервера:

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

Ограничение на уровне сервера с перекрытием для авторитетных зон

В этом случае определяется допустимое множество внутренних клиентов, которые могут передавать запросы к name-серверу. Для этого соответствующее acl утверждение таково:

acl "internal_hosts" { 192.158.43.3, 192.158.43.6, 192.158.44.56; };

Опцией на уровне сервера следует указать ограничение, чтобы запросы могли исходить только от данных клиентов:

options {
  allow_query { internal_hosts; };
};

Опция может быть перекрыта указанием зон, для которых данный name-сервер является авторитарным (тем самым разрешая запросы, касающиеся ресурсов в данной зоне от всех клиентов):

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow_query { any; };
};

Ограничение всех рекурсивных запросов конкретным множеством IP-адресов

Ограничение на уровне сервера:

options {
  allow_recursion { internal_hosts; };
};

Ограничение рекурсии с помощью views

Цель создания views состоит в логической комбинации клиентов (на основе IP-адресов) и зон, для которых будут поддерживаться рекурсивные запросы и для которых они не будут поддерживаться. В следующем примере view recursion_view дает возможность определить область IP-адресов и зон, которым разрешено передавать рекурсивные запросы; no_recursion_view означает запрещение рекурсии.

view recursion_view {
  match-clients ( internal_hosts; };
  recursion yes;
};
view no_recursion_view {
  match-client { any; };
  recursion no;
};

Ограничение участников транзакции зонной пересылки

Авторитетные name-серверы (особенно первичные) должны быть сконфигурированы с утверждением управления доступом allow-transfer, содержащим список хостов, с которых запросы зонной пересылки могут приниматься. Это ограничивает DoS-атаки и использование возможных ошибок (exploits), а также неконтролируемое распространение информации о внутренних ресурсах. Единственными name-серверами, которым необходимо периодическое обновление своих зонных файлов, являются вторичные name-серверы. Следовательно, зонная пересылка от первичного name-сервера должна разрешаться только к вторичным name-серверам. Зонная пересылка должна быть полностью запрещена на вторичных name-серверах. Аргумент списка соответствующих адресов в подутверждении allow-transfer должен состоять из IP-адресов вторичных name-серверов, которые указаны в NS множества ресурсных записей, и "невидимых" вторичных name-серверов, которые указаны только в этом подутверждении.

Команда для создания ACL valid_secondary_NS с IP-адресами трех вторичных name-серверов следующая:

acl "valid_secondary_NS" {
  224.10.229.5;
  224.10.235.6;
  224.10.245.25;
};

Подутверждение allow-transfer может быть использовано в утверждении zone и в утверждении options. Если оно используется в утверждении zone, то ограничивает зонную пересылку для данной зоны; если используется в утверждении options, ограничивает зонную пересылку для всех зон в name-сервере.

Подутверждение allow-transfer на уровне сервера является следующим:

options {
  allow-transfer { valid_secondary_NS; };
};

Подутверждение allow-transfer на уровне зоны является следующим:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-transfer { valid_secondary_NS; };
};

Предыдущие утверждения используются на первичных name-серверах. На вторичных и невидимых name-серверах зонная пересылка должна быть запрещена, как показано ниже:

zone "example.ru" {
  type slave;
  masters { 224.239.5.1 };
  file "zonedb_bak.example.ru";
  allow-transfer { none; };
};

Ограничение участников транзакции динамического обновления

Динамические обновления зонного файла могут осуществляться только для зонного файла, находящегося на первичном name-сервере зоны. По умолчанию динамические обновления отключены как в BIND 8, так и в BIND 9. Динамические обновления управляются использованием одного из следующих двух утверждений в BIND:

• allow-update ;
• update-policy (доступно только в версиях BIND 9).

Эти утверждения могут быть указаны только на уровне зоны, а не на уровне сервера. Следовательно, они являются подутверждениями внутри утверждения zone. Подутверждение allow-update дает возможность указать ограничения динамического обновления на основе IP-адресов и разделяемого секрета (также называемого TSIG key). Сначала обсудим использование allow-update с помощью указания только IP-адресов, а затем — использование утверждения allow-update с TSIG-ключами.

Утверждение update-policy дает возможность указать ограничения динамического обновления только на основе TSIG-ключей, при этом ограничения могут быть указаны более детально. Подутверждение allow-update определяет права доступа, касающиеся модификаций, ко всем записям в зоне. Подутверждение update-policy может быть использовано для ограничения прав доступа по модификации к одному или более типам ресурсных записей (например, A ресурсные записи).

Для использования утверждения allow-update должен быть создан список соответствующих адресов. Команда для создания ACL DU_Allowed_List с одним IP-адресом следующая:

acl "DU_Allowed_List" {
  192.249.12.21;
};

ACL DU_Allowed_List (содержащий IP-адреса хостов, которым разрешено посылать запросы динамического обновления для изменения содержимого зоны example.ru ) используется внутри подутверждения allow-update утверждения zone следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-update { DU_Allowed_List; };
};

Запросы динамического обновления обычно исходят от таких хостов, как DHCP-серверы, которые динамически связывают IP-адреса с хостами. После того, как они назначат IP-адрес новому хосту, им нужно сохранить информацию отображения доменного имени на IP-адрес (созданием A ресурсной записи) и отображения адреса на доменное имя (созданием PTR ресурсной записи) в первичном авторитетном name-сервере для зоны. Создание данной информации происходит посредством динамических обновлений.

Ограничение участников транзакции DNS NOTIFY

После того как зонные пересылки между серверами установлены, хорошо бы гарантировать, что вторичные name-серверы будут информироваться об изменениях в данных зонного файла посредством получения уведомления. По умолчанию сообщение уведомления посылается всякий раз, когда первичный name-сервер определил, что было сделано изменение в зонном файле. Он посылает сообщение DNS NOTIFY каждому name-серверу, перечисленному в NS -множестве ресурсных записей в зоне, потому что эти серверы считаются вторичными name-серверами зоны. Администратор DNS должен оставить выполнение этой транзакции, потому что это позволяет быстро распространять обновления на вторичные name-серверы. Однако, если администратор хочет выключить данную функциональность для конкретной зоны, следует использовать подутверждение notify в утверждении zone для данной зоны:

zone "example.ru" {
  type master;
  notify no;
  file "zonedb.example.ru";
};

Если существуют дополнительные серверы, на которые администратор хочет посылать сообщение DNS NOTIFY (например, "невидимый" вторичный сервер), должно быть добавлено подутверждение also-notify в утверждение zone, и IP-адреса дополнительных серверов должны быть указаны в качестве значений параметров следующим образом:

zone "example.ru" {
  type master;
  also-notify { 192.168.25.2; };
  file "zonedb.example.ru";
};

Получатель сообщения DNS NOTIFY, которым является вторичный name-сервер, по умолчанию разрешает получать сообщения уведомления только от первичного name-сервера. То, что данный name-сервер является вторичным для первичного name-сервера, указывается посредством подутверждения masters в утверждении zone. Если вторичный name-сервер хочет получать сообщения уведомления также и от других серверов, следует добавить подутверждение allow-notify в утверждение zone, и соответствующие IP-адреса этих серверов:

zone "example.ru" {
  type slave;
  allow-notify { 193.168.25.4; };
  file "zonebak.example.ru";
  masters { 192.168.25.1; };
};