DNS (система доменных имен) — это метод с долгой историей. Он позволяет назначать доменные имена компьютерам с IP-адресами, чтобы компьютеры имели символьные имена. Например, компьютер с IP-адресом 207.46.193.254 — это сервер Microsoft www. Майкрософт. DNS хорошо спроектирован и большую часть времени работает очень хорошо. Однако всегда возникают неприятные ситуации, и они могут ударить, причинив администраторам головную боль. Так как же найти признаки его неудачи? Какие области вашей системы DNS не идеальны?
Есть ли какой-то образец, которому нужно следовать? Ответ — да. Вот семь грехов DNS-серверов:
1. Используйте старую версию BIND.
Bind, как программное обеспечение DNS-сервера с открытым исходным кодом, в настоящее время является наиболее широко используемым программным обеспечением DNS-сервера в мире. Почти большинство старых версий BIND имеют серьезные, хорошо известные уязвимости. Злоумышленники могут использовать эти уязвимости, чтобы вывести из строя наши DNS-серверы имен и поставить под угрозу хосты, на которых они работают. Поэтому вам следует обязательно использовать последнюю версию BIND и своевременно исправлять ее.
2. Поместите все важные серверы доменных имен в одну подсеть.
В этом случае выход из строя какого-либо оборудования, например коммутатора или маршрутизатора, или сбой сетевого подключения может помешать пользователям Интернета получить доступ к вашему веб-сайту или отправить вам электронные письма.
3. Разрешить рекурсию неавторизованным запросам.
Если установлена следующая ситуация:
(рекурсия да|нет; [да]
разрешить-рекурсию {address_match_list} [все хосты];
|
Это небезопасно. Здесь опция рекурсии указывает, будет ли Name запрашивать другие серверы доменных имен от имени клиента. Серверы имен обычно не настроены на отключение рекурсии. По крайней мере, нам следует разрешить рекурсию для наших собственных клиентов, но отключить рекурсию для внешних запросов. Потому что, если вы можете обрабатывать рекурсивные запросы для любого клиента, вы подвергаете сервер имен отравлению кэша и атакам типа «отказ в обслуживании».
4. Разрешить неавторизованным вторичным серверам имен выполнять передачу зон.
Перенос зоны — это процесс копирования файлов базы данных зоны между несколькими DNS-серверами. Если вы предоставляете услуги переноса зоны произвольным запросам, вы открываете сервер доменных имен для злоумышленников, что приводит к сбою сервера.
5. DNS-переадресатор не используется.
Сервер пересылки DNS — это сервер, который выполняет DNS-запросы от имени других служб DNS. Многие программы серверов имен, включая DNS-серверы Microsoft и некоторые старые серверы имен BIND, не обеспечивают адекватной защиты от отравления кэша, а другое программное обеспечение DNS-серверов также имеет уязвимости, которые могут быть использованы злоумышленниками. Но многие администраторы позволяют этим серверам имен напрямую запрашивать другие серверы имен в Интернете, вообще не используя серверы пересылки.
6. Неверная установка значения Start of Authority (SOA).
SOA отмечает начало данных зоны и определяет параметры, влияющие на всю зону. Многие администраторы устанавливают слишком низкое значение зоны, что может привести к сбоям в работе системы, когда запросы на очистку или передачу зон начинают завершаться сбоем. Поскольку RFC изменил определение SOA, некоторые люди сбрасывали отрицательный TTL кэширования, в результате чего он стал слишком высоким.
7. Несовпадение записей NS в данных авторизации и зоны.
Некоторые администраторы добавляют или удаляют первичные серверы имен, но забывают внести соответствующие изменения в данные делегирования своей зоны (так называемые данные делегирования). Это увеличит время, необходимое для разрешения доменных имен, и снизит гибкость.
Конечно, это лишь некоторые распространенные ошибки, которые могут допускать администраторы, но они могут служить основным справочником по настройке вашего DNS-сервера.