9 ошибок Windows DNS, которых следует избегать

Если вы запускаете службы DNS на сервере Windows, то у вас, вероятно, работает Active Directory, ваши DNS-серверы также являются вашими контроллерами домена, а ваши клиенты настроены на использование ближайшего контроллера домена для DNS. Это хорошее начало, но есть несколько неправильных конфигураций в DNS, которые возникают снова и снова. Давайте рассмотрим девять ошибок, которые могут вызвать проблемы с любой сетевой средой, если DNS-сервер настроен неправильно.

1. Настройка одинокого острова

Когда вы настраиваете свой первый контроллер домена в лесу, у вас действительно нет другого выбора, кроме как указать сервер на себя для DNS. Однако не оставляйте это так и не делайте этого для любого другого сервера. Как только ваш второй контроллер домена будет запущен и запущен, перенастройте первый, чтобы использовать второй для DNS, а второй, чтобы использовать первый. Как только вы создадите третий, добавьте его в смесь, чтобы ни один контроллер домена не мог полагаться на себя для DNS (используя свой локальный ip.addr или 127.0.0.1.). Когда контроллеры домена используют себя для DNS, особенно когда DNS интегрирован с AD, они могут стать изолированными и начать сбой репликации. Когда они используют другие контроллеры домена для DNS, вы обнаружите меньше общих проблем с репликацией AD.

2. DNS-серверы слишком далеко от клиентов

Сократите время отклика DNS для своих клиентов. Я стремлюсь к менее 25 мс, но менее 50 мс достаточно. Для этого вам нужно иметь локальный DNS-сервер для ваших клиентов. Если у вас нет контроллеров домена на каждом сайте, вы должны по крайней мере развернуть DNS-сервер только для кэширования на какой-либо системе в расположении, например на сервере файлов и печати. Когда DNS рядом, все остальные приложения будут работать лучше, потому что разрешение имен происходит локально.

3. Не хранить зоны AD в AD

Интегрированные зоны AD хранятся и реплицируются с помощью Active Directory, и их можно настроить для репликации на все DNS-серверы в домене или лесу. Это обеспечивает высокую доступность, отказоустойчивость и простоту настройки при работе DNS на контроллерах домена. Это лучший способ использовать внутренний DNS.

4. Требование безопасных обновлений

Это может вызвать некоторые комментарии, но потерпите меня немного. Когда вы запускаете DNS, интегрированный в AD, у вас есть возможность разрешить динамические обновления и потребовать, чтобы они были безопасными… то есть аутентифицированы членами домена. Все ваши серверы и рабочие станции (подключенные к домену и работающие под управлением Windows) могут автоматически регистрироваться в DNS. Это замечательно, если вы работаете исключительно с Windows, но если у вас есть клиенты и серверы для Linux или Mac, это оставляет их в дураках. Разрешите динамические обновления или, если все ваши системы, не присоединенные к домену, являются рабочими станциями, скомпрометируйте и разрешите DHCP регистрировать записи DNS для клиентов. Чем больше систем вы зарегистрировали в DNS, тем проще вам будет их находить и управлять ими.

5. Не настраивать PTR

Обратные записи DNS, называемые записями PTR, преобразуют ip.addrs в имена, что значительно упрощает запуск системы, когда вы знаете, какой у нее IP-адрес, но не знаете, что это такое. Слишком часто администраторы предпочитают не настраивать зоны in-addr.arpa, в которых хранятся записи PTR, нарушая эту зачастую критически важную функцию. Не будь тем парнем!

6. Пересылка далеко-далеко

Точно так же, как вы хотите, чтобы DNS-серверы находились рядом с клиентами, вы хотите, чтобы ваши DNS-серверы разрешались как можно ближе к самим себе. Сегодня все больше и больше сервисов в Интернете используют CDN и несколько экземпляров, которые используют GeoDNS или другие подходы с учетом сайта для предоставления локальных ответов глобально распределенным клиентам. Если ваш контроллер домена в токийском офисе настроен на переадресацию на контроллер домена в Далласе для разрешения проблем, вы обнаружите, что проблемы в Интернете слишком медленны для ваших пользователей в Японии, потому что это долгий путь, чтобы решить проблему. имя, и разрешенное имя чаще всего не будет локальным для пользователей.

7. Настройка цикла переадресации

Хотите разорвать WAN-соединение за два простых шага? Настройте DNS-сервер в местоположении A для переадресации на сервер в местоположении B. Настройте DNS-сервер в местоположении B для переадресации на сервер в местоположении A. Запросите у одного из них имя. Неважно, какое имя, если оно находится в домене, для которого ни один из них не является авторитетным. Запрос A, но A не будет знать, поэтому он запросит B. B не узнает, поэтому он запросит A. Неважно, что A задал его, он все равно будет запрашивать A. И A не будет заботиться что он только что задал B тот же вопрос… он получил запрос, он не знает ответа, поэтому он запрашивает B. DNS-запросы не имеют состояния. Там нет ни TTL, ни маркера происхождения, ни чего-то еще. Два сервера будут зацикливать запрос друг на друге до бесконечности, пока вы не убьете один из них или сеть не выйдет из строя. Конечно, это весело для стресс-тестирования сети, но не столько для выполнения работы.

8. Не настраивать старение и очистку

Точно так же, как вашим клиентам и вашим DHCP-серверам должно быть разрешено динамически регистрировать записи DNS, эти записи должны поддерживаться. Windows DNS предлагает устаревание и очистку, которая просматривает записи старше X дней и удаляет их из DNS. Однако по умолчанию это отключено, что может привести к появлению старых или устаревших данных в DNS, включая регистрации для систем, которые вы закрыли много лет назад. Поддержание чистоты DNS упрощает поиск ресурсов и устранение неполадок. Старение и очистка обеспечивают автоматическое поддержание чистоты DNS.

9. Разрешение передачи зоны извне и запрет внутри

Передача зон позволяет DNS-серверу предоставлять полный набор записей для пространства имен в ответ на один запрос. Когда одному DNS-серверу в авторизованной зоне необходимо обновить свой полный файл зоны или когда администратору нужно что-то проверить, это упрощает просмотр всей зоны. Но снаружи, разрешение переноса зон делает слишком легкой разведку для злоумышленника. Внутренние передачи зон должны быть разрешены, чтобы помочь администраторам выполнять свою работу. Внешне вы не должны разрешать передачу зон, кроме как на другие DNS-серверы, которыми вы управляете, так что кто-то, кто вас контролирует, по крайней мере, должен работать на это!

Помните старую поговорку: «Если DNS недоволен, значит, никто не счастлив». Правильная настройка DNS и обеспечение того, чтобы она оставалась такой, является ключом к тому, чтобы ваша сеть, ваши приложения и ваши пользователи получали наилучшие впечатления. Избегание этих девяти ловушек помогает убедиться, что это произойдет.