Создание доверенной цепочки и проверка подписи (DNSSEC-OP8)

До тех пор, пока все зоны не станут подписанными, возможна ситуация, при которой зона является подписанной, но ее родитель не является подписанной зоной. Единственной точкой доверия для поддерживающего DNSSEC resolver’а в этом случае может считаться заранее сконфигурированный открытый ключ подписывающей стороны. При отсутствии другого источника, подтверждающего достоверность открытого ключа подписывающей стороны, требуется, чтобы открытый ключ был получен безопасным способом. В противном случае, если существует домен X, который может подтвердить достоверность открытого ключа домена Y, resolver может установить доверие к подписывающей стороне Y, используя X. Последовательность зон в дереве DNS, с помощью которых resolver устанавливает доверие к открытому ключу подписывающей стороны, называется цепочкой доверия.

Будем считать, что цепочка доверия начинается с домена X и заканчивается доменом Y. Обычно домен X является непосредственным родителем Y и называемая родительской зоной. Родительская зона обеспечивает доказательство достоверности открытого ключа дочерней зоны, подписывая ее ключ. Данная подпись хранится в ресурсной записи, называемой Delegation Signer (DS). Родительская зона также должна быть подписанной зоной, потому что неподписанная зона не умеет создавать подписи. Таким образом, подписанная зона может быть одного из следующих типов.

Изолированная безопасная зона – зона, которая является самоподписанной. Причина существования изолированных зон состоит в том, что родительская зона не является безопасной или нет возможности установить безопасное делегирование открытого ключа дочерней зоны и, следовательно, невозможно установить достоверность открытого ключа дочерней зоны, используя открытый ключ родительской зоны. В этом случае цепочки доверия не существует.
Глобально безопасная зона – ее родительская зона и, возможно, один или более предков вверх по DNS-дереву являются подписанными. При существовании такой иерархии подписанных зон и соответствующей иерархии сконфигурированных ключей resolver обычно имеет в качестве начала цепочки доверия открытый ключ зоны, которая является вершиной иерархии подписанных зон.
Этот открытый ключ называется доверенный anchor. В resolver’ е может существовать более одного ключа, которые являются доверенными anchor’ами и могут использоваться для построения цепочки доверия к открытому ключу зоны, чьи подписи resolver хочет проверять.

При защите данных зоны с помощью цифровой подписи в изолированной безопасной зоне следует выполнить следующие действия:

создать пару открытый / закрытый ключ;
обеспечить безопасное хранение (если необходимо, отдельно от name-сервера) закрытого ключа;
опубликовать открытый ключ с помощью включения ресурсной записи DNSKEY в зонный файл;
создать цифровые подписи для данных зоны (подписывание зоны).

Для глобально безопасной зоны существуют дополнительные задачи. Чтобы обеспечить возможность создания цепочки доверия, зона должна безопасным образом (внешним по отношению к сервисам DNS) передать родительской зоне свой открытый ключ (KSK-public). Затем родитель создает хэш этого открытого ключа дочерней зоны и хранит его в своей зоне в виде новой ресурсной записи, называемой DS. Он подписывает эту ресурсную запись DS, создавая ресурсную запись RRSIG. Родителю передается ключ KSK, а не ключ ZSK, потому что в противном случае происходило бы следующее. Всякий раз, когда зона изменяет свой ZSK, ее родитель должен был бы быть уведомлен о новом ключе. При этом родителю приходилось бы создавать новую ресурсную запись DS и снова подписывать ее. Для уменьшения подобной административной нагрузки родительской зоне передается ключ KSK. KSK используется для подписывания только ресурсных записей DNSKEY; все остальные ресурсные записи в зонном файле подписываются ZSK. KSK является тем ключом, который опубликовывается у родителя. Родитель создает ресурсную запись DS, содержащую ключ KSK дочерней зоны, создает подпись для данного KSK и размещает ее в ресурсной записи RRSIG. Ключ KSK создается достаточно большим (например, 2048 бит) по сравнению с ключом ZSK, который может быть, например, длиной 1024 бит и, следовательно, должен изменяться менее часто.

Следовательно, он доверяет ресурсным записям NS и DS в зоне .ru. Из ресурсной записи NS и связанных с ней ресурсных записей resolver определяет, что авторитетный name-сервер для example.ru есть ns.example.ru, и он также знает его IP-адрес. Используя данную информацию, он идет на ns.example.ru и получает ключ KSK для example.ru из его множества ресурсных записей DNSKEY. Он вычисляет хэш данного ключа и сравнивает его с хэшем в ресурсной записи DS его родительской зоны .ru. Равенство этих двух хэшей означает, что ссылка из .ru зоны на example.ru зону аутентифицирована; аутентифицирован также и ключ KSK example.ru зоны. Так как ключ ZSK подписан ключом KSK example.ru, resolver может получить ключ ZSK example.ru аутентифицированным способом. Так как ключ ZSK подписывает все ресурсные записи в example.ru, действительность любого подписанного ответа из данной зоны может быть определена с использованием ключа ZSK, который уже аутентифицирован.

Информация делегирования в родительской зоне в случае глобально безопасной зоны содержит следующее:

Ресурсные записи NS для дочерней зоны, которые включают в себя ссылки на name-сервера дочерних зон.
Относящиеся к ним ресурсные записи. Они определяют расположение серверов, перечисленных в ресурсных записях NS.
Ресурсную запись DS, которая включает в себя хэш KSK дочерней зоны.
Ресурсную запись RRSIG, которая является подписью для ресурсной записи DS.

Просуммируем дополнительные задачи, которые имеют место при глобально безопасной зоне.

Безопасная пересылка открытого ключа KSK зоны своему родителю. Данная пересылка выполняется внешним способом и может не включаться ни в какие DNS-транзакции.
Родитель создает хэш открытого ключа KSK дочерней зоны и хранит хэш в ресурсной записи DS. Родитель также создает цифровую подпись (ресурсную запись RRSIG) для данной ресурсной записи DS. Эта запись включается в информацию делегирования.

Зона, подписывающая ответ, является конечной точкой в цепочке доверия. Предварительно необходимо установить доверие к ZSK для зоны. Доверие к ZSK зоны устанавливается посредством следующих операций:

получение аутентифицированной ссылки от родителя;
аутентификация KSK дочерней зоны.

Для понимания обработки аутентифицированной ссылки, которая находится у родителя, необходимо посмотреть, как обрабатывается обычная ссылка DNS. В обычном DNS-запросе зона, которая не имеет авторитетной информации, относящейся к запросу для доменного имени в дочерней зоне, предоставляет ссылку, указывая множество ресурсных записей NS и соответствующие относящиеся к ним ресурсные записи (ресурсные записи, которые содержат IP-адреса серверов, указанных в ресурсных записях NS). При обычной обработке DNS-запроса следование по этим ссылкам будет следующим шагом обработки. Однако данный процесс является недостаточным с точки зрения установления цепочки доверия; информация о множестве ресурсных записей NS и связанных с ними ресурсными записями не может считаться аутентичной, потому что они не подписаны закрытым ключом аутентичного источника. Аутентификацию данной информации о ссылке родитель предоставляет криптографическим способом с помощью ресурсной записи DS.

Рассмотрим пример того, как поддерживающий DNSSEC resolver проверяет правильность DNS-ответа от подписанной зоны example.ru. Resolver, следуя по своей цепочке доверия, начинающейся от доверенного anchor’а, аутентифицирует открытый ключ для зоны .ru и тем самым доверяет ему.

Содержание раздела