Транзакции DNS

Безопасность зонных пересылок с использованием TSIG

Для пары серверов, участвующих в транзакциях зонных пересылок, указывается, что они должны использовать ключ, определенный в утверждении key. Такая пара обычно состоит из первичного name-сервера и вторичного name-сервера. Первичный name-сервер конфигурируется таким образом, чтобы принимать запросы зонной пересылки только от вторичных name-серверов, которые посылают МАС с использованием поименованного ключа, передаваемого в сообщении запроса зонной пересылки. Конфигурация создается с использованием подутверждения allow-transfer в утверждении zone. Пример подутверждения allow-transfer, которое указывает, что первичный name-сервер должен разрешать запросы зонной пересылки только для зоны example.ru от name-серверов, использующих ns1-ns2.example.ru ключ, выглядит следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-transfer { key {ns1-ns2.example.ru}; };
};

Вторичному name-серверу указывается использовать ключ ns1-ns2.example.ru в запросе зонной пересылки к первичному name-серверу, задействуя утверждение server.

Безопасность динамических обновлений с использованием TSIG

Ограничения динамических обновлений, основанные на ключах TSIG, могут быть указаны в BIND 8.2 и более поздних версиях использованием подутверждения allow-update утверждения zone. Аргументом данного утверждения является ключевое слово key, за которым следует имя TSIG-ключа.

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-update { key {dhcp-server.example.ru.}; };
};

Заметим, что, хотя строка dhcp-server.example.ru. выглядит как FQDN, на самом деле она обозначает имя TSIG-ключа. В данном примере любой хост, который обладает ключом с именем dhcp-server.example.ru., может посылать запросы динамического обновления (добавления, удаления или модификации ресурсных записей) зонного файла (для зоны example.ru ), который расположен на первичном авторитетном name-сервере.

Конфигурирование ограничений перенаправления динамических обновлений с использованием ключей TSIG

Динамическим обновлениям разрешено копирование зонного файла на первичный авторитетный name-сервер только потому, что он является "writable". При этом автоматически не предполагается, что только первичный авторитетный name-сервер может принимать запросы динамического обновления. В BIND 9.1.0 и более поздних версиях разрешается вторичным name-серверам принимать запросы динамического обновления и перенаправлять их первичному авторитетному name-серверу. В данном сценарии, если не существует ограничений, основанных на идентификации хостов, с которых вторичный name-сервер может перенаправлять такие запросы динамического обновления, это эквивалентно обходу ограничений динамического обновления, указанным в первичном name-сервере, потому что запрос может исходить с любого хоста к вторичному name-серверу и перенаправляться на первичный name-сервер. Для решения данной проблемы было добавлено новое подутверждение allow-update-forwarding в версии BIND, которые имеют возможность перенаправления динамических обновлений. Пример такого allow-update-forwarding утверждения с использованием TSIG-ключей следующий:

zone "example.ru" {
  type slave;
  file "backupdb.example.ru";
  allow-update-forwarding { key {dhcp-server.example.ru.}; };
};

Конфигурирование более точных ограничений динамического обновления с использованием TSIG-ключей

Подутверждение allow-update определяет ограничения динамического обновления, которые основаны на отправителях запросов динамических обновлений (конкретное множество хостов, идентифицируемых по IP-адресу или обладающих TSIG-ключом), но не на содержимом зонных записей. Для указания ограничений доступа ( grant или deny ) к динамическим обновлениям, основанным на комбинации имен домена или поддомена и типов ресурсных записей ( A, MX, NS и т.п.), BIND 9 и более поздние версии предоставляют подутверждение update-policy в утверждении zone. Эти ограничения в подутверждении update-policy основаны на TSIG-ключе. Другими словами, подутверждение update-policy указывает, каким TSIG ключам (держателям ключей) разрешено выполнять динамические обновления для каких доменов или поддоменов и типов ресурсных записей внутри данного домена или поддомена.

Общая форма update-policy утверждения следующая:

update-policy {
  (grant | deny) TSIGkey nametype name [type]
};

где семантика каждого компонента утверждения такова:

• grant / deny – разрешить / запретить динамическое обновление для комбинации, которая следует далее.
• TSIGkey – имя TSIG-ключа, используемого для аутентификации запроса обновления.

• nametype – может быть одним из следующих значений, с соответствующей семантикой:

  • name – ограничение, применяемое к имени домена, которое указано в следующем поле name.
  • subdomain – ограничение, применяемое к поддоменам домена, который указан в следующем поле name.
  • wildcard – ограничение, применяемое к множеству доменов, которые указаны с использованием wildcard синтаксиса (например, *) в следующем поле name.
  • self – ограничение, применяемое к домену, который является тем же самым, что и в поле TSIGkey (например, имя домена, чьи записи являются модифицируемыми, такое же, что и у ключа, используемого для аутентификации запроса динамического обновления). При таком использовании содержимое поля name становится лишним, но, тем не менее, должно использоваться в утверждении (т.е. поле name не может быть пустым).
• name – применяется для указания имени домена. Используемый синтаксис и домены, которые указывает данный параметр, основаны на значении, заданном в поле nametype (например, если поддомен является значением поля nametype, то все поддомены используемого имени домена охватываются данным утверждением).
• type – необязательное поле, которое может содержать любой существующий тип ресурсных записей (за исключением NSEC -типа) или wildcard тип ANY ( ANY означает все типы ресурсных записей, за исключением NSEC -типа). Если параметр опущен, то это означает все типы ресурсных записей, за исключением SOA, NS, RRSIG и NSEC. Также возможно использование нескольких типов ресурсных записей, разделенных пробелами (например, A NS ).

Примеры update-policy утверждений и связанная с ними семантика приведены ниже.

Предположим, что существует домен sales.example.ru внутри example.ru и что name-сервер использует TSIG ключ, который имеет то же самое имя, что и имя его домена (т.е. sales.example.ru ). Все динамические обновления от sales.example.ru могут быть ограничены ко всем ресурсным записям данного домена следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  update-policy { grant sales.example.ru. self sales.example.ru.; };
};

Все динамические обновления от sales.example.ru могут быть ограничены только типами ресурсных записей A и MX данного домена следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  update-policy {
  grant sales.example.ru. self sales.example.ru. A MX; };
};