Дополнительные меры защиты для DNS Query / Response
Спецификации DNSSEC для защиты транзакций DNS Query / Response определяет следующие типы ответов:
- DNS-ответы от удаленных авторитетных name-серверов к локальным рекурсивным name-серверам;
- DNS-ответы от удаленных кэширующих name-серверов к локальным рекурсивным name-серверам.
Так как большинство запросов первоначально исходят от stub resolver’а (от имени ПО клиента, требующего доступ к ресурсу в Интернете), защита сообщения DNS ответа должна также обеспечиваться для stub resolver’а от рекурсивного name-сервера. Способ обеспечения защиты на этом участке, который часто называется DNS "last hop", определяется природой stub resolver’а и топологией сети.
Stub resolver может:
-
не поддерживать DNSSEC;
-
– поддерживать DNSSEC и не проверять правильность ответа;
-
поддерживать DNSSEC и проверять правильность ответа.
Большинство stub resolver’ов, существующих сегодня, не поддерживают DNSSEC. Другими словами, они не имеют возможности проверить цифровые подписи, связанные с полученными множествами ресурсных записей, и также не могут отличить аутентифицированный ответ (проверяя его подпись) от неаутентифицированного ответа, передаваемого им их локальными рекурсивными name-серверами. Чтобы создать полную end-to-end защиту для DNS Query / Response, эти типы stub resolver’ов как минимум должны иметь возможность выполнять аутентификацию источника и проверку целостности данных в ответах, пришедших от рекурсивного name-сервера, который предоставляет им сервис разрешения имен. Такая возможность может быть обеспечена использованием подхода НМАС, заданного в TSIG (где описано использование НМАС для защиты транзакций зонных пересылок и динамических обновлений). В качестве альтернативы защиту можно обеспечить с помощью других механизмов сетевой безопасности, таких как IPsec. Независимо от механизма, используемого для обеспечения безопасности канала "last hop" (от рекурсивного name-сервера к stub resolver), данная возможность также должна присутствовать в поддерживающих DNSSEC и не проверяющих правильность ответа stub resolver’ах в дополнение к не поддерживающим DNSSEC stub resolver’ам.
Поддерживающий DNSSEC, но не проверяющий правильность ответа stub resolver может увеличить доверие к этому ответу, проверяя значение AD бита в заголовке сообщения в полученном ответе. Данные типы stub resolver’ов могут затем использовать этот бит в качестве признака того, что рекурсивный name-сервер имеет возможность проверять действительность подписей для данных в ответе.
В некоторых ситуациях установление доверенного пути между stub resolver’ами и рекурсивными name-серверами не предоставляется возможным. Примером является ситуация, когда рекурсивный name-сервер не расположен в административном домене предприятия, а выполняется у провайдера. В такой ситуации end-to-end защита может быть обеспечена только при наличии поддерживающего DNSSEC stub resolver’а. Поддерживающий DNSSEC stub resolver может уведомить локальный рекурсивный name-сервер, что он хочет сам выполнить проверку действительности подписи, установив Checking Disabled (CD) бит в свои сообщения запроса.
