3.1. Аутентификация источника данных и проверка целостности
DNSSEC обеспечивает аутентификацию путем связывания криптографических цифровых подписей с наборами данных DNS RRset. Эти цифровые подписи хранятся в новых записях RRSIG. Обычно имеется один закрытый (private) ключ для подписывания данных зоны, но можно использовать и множество ключей. Например, могут использоваться отдельные ключи для каждого из различных алгоритмов создания цифровой подписи. Если защищенный преобразователь надежным путем получает открытый ключ зоны, он может аутентифицировать подписанные данные зоны. Важной концепцией DNSSEC является то, что ключ, подписывающий данные зоны, связывается с самой зоной, а не с уполномоченными серверами этой зоны. Открытые ключи для механизмов аутентификации транзакций DNS также могут появляться в зонах, как описано в [RFC2931], но расширения DNSSEC сами по себе не имеют дела с защитой объектов данных DNS и каналов для выполнения транзакций DNS. Ключи, связанные с защитой транзакций, могут храниться в различных типах RR. Дополнительную информацию можно найти в [RFC3755].
Защищенный преобразователь может получить открытый ключ зоны с помощью доверенной привязки (trust anchor), заданной в конфигурации преобразователя или полученной обычными средствами преобразования DNS. Для второго варианта ключи хранятся в записях нового типа - DNSKEY RR. Отметим, что закрытые ключи, используемые для подписывания зоны, должны храниться отдельно с обеспечением защиты. Для надежного получения публичных ключей с помощью преобразования DNS resolution, сам ключ подписывается с помощью аутентификационного ключа, заданного в конфигурации, или другого ключа, который был заранее аутентифицирован. Защищенные преобразователи аутентифицируют данные зоны для формирования аутентификационной цепочки от полученного последним публичного ключа обратно к ранее известному аутентификационному ключу, который, в свою очередь, задается в конфигурации преобразователя или должен быть получен и проверн заранее. Следовательно, в конфигурации преобразователя должна быть задана по крайней мере одна доверенная привязка.
Если заданная в конфигурации доверенная привязка явлюяется ключом подписывания зоны, она будет аутентифицировать соответствующую зону; если заданный в конфигурации ключ является ключом для подписывания, он будет аутентифицировать ключ подписывания зоны. Если заданная в конфигурации доверенная привязка представляет собой хэш ключа, а не сам ключ, преобразователь может получить ключ с помощью запроса DNS. Чтобы помочь защищенным преобразователям создавать аутентификационные цепочки, защищенные серверы имен пытаются передавать сигнатуру (сигнатуры), требуемую для аутентификации открытого ключа зоны, в сообщении DNS вместе с самим ключом, благо в сообщении для этого имеется место.
Записи типа DS RR упрощают решение некоторых административных задач, связанных с подписыванием делегирования через организационные границы. Набор DS RRset находится в точке делегирования родительской зоны и показывает открытый ключ (ключи), используемый для самоподписывания DNSKEY RRset на вершине делегированной дочерней зоны. Администратор дочерней зоны, в свю очередь, использует закрытый ключ (ключи), соответствующий одному или нескольким открытым ключам в данном наборе DNSKEY Rrset, для подписывания данных дочерней зоны. Типовая цепочка аутентификации, следовательно, будет иметь вид DNSKEY->[DS->DNSKEY]*->RRset, где символ * обозначает субцепочки DS->DNSKEY (0 или более). DNSSEC разрешает и более сложные цепочки аутентификации (такие, как дополнительные уровни DNSKEY RR, подписывающие другие DNSKEY RR внутри зоны).
Защищенный преобразователь обычно создает цепочку аутентификации от корня иерархии DNS вниз к ветвям зон, на основе заданных в конфигурации данных о корневом открытом ключе. Локальная политика может также позволять защищенному преобразователю использовать один или множество открытых ключей (или их хешей), отличных от корневого открытого ключа, может не обеспечивать данных о корневом открытом ключе или может запрещать преобразователю использовать открытые ключи по любым причинам, даже если эти ключи корректно подписаны и подписи проверены. DNSSEC обеспечивает механизмы, посредством которых защищенный преобразователь может определить является ли подпись Rrset корректной с точки зрения DNSSEC. Однако последнее слово при анализе аутентификации для ключей и данных DNS остается за локальной политикой, которая может расширить или переназначить расширения протокола, определенные в этом наборе документов (см. также главу 5).