DNS и DHCP: первые шаги и первые грабли

Windows 2000 Server вышел в феврале, и мы его наконец развернули. Первое, во что упёрлись: Active Directory без DNS не работает вообще никак. NT 4 жил на WINS и NetBIOS, а теперь домен требует нормальную зону, записи SRV, и чтобы все клиенты смотрели именно во внутренний резолвер. Значит, ставим DNS. И заодно DHCP - двадцать машин с прописанными вручную адресами это не инфраструктура, это просто боль.

Как это выглядело до

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

Ставим

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

DNS настроили под внутреннюю зону - пусть будет corp.adg.local. Создали forward lookup zone, добавили A-записи для сервера и пары ключевых хостов, настроили форвардинг на DNS провайдера для внешних имён. Active Directory развернулась, домен поднялся, Kerberos заработал. Первый день прошёл нормально.

Второй день тоже прошёл нормально.

На третий день перестало работать делегирование зоны.

Что сломалось и почему

Мы делегировали подзону servers.corp.adg.local на тот же сервер - просто чтобы держать серверные записи отдельно. Казалось разумным. Клиенты начали получать SERVFAIL на запросы к хостам в этой подзоне.

Разбирались часа три. Симптомы путали: nslookup с указанием сервера напрямую работал, а через клиентский резолвер - нет. Это навело на мысль, что проблема не в самих зонных файлах.

Нашли две вещи одновременно:

Первое - запись NS в родительской зоне. При создании делегирования мастер W2K DNS добавил NS-запись для подзоны, но не добавил glue-запись - A-запись самого NS-сервера. Резолвер спрашивал: «кто отвечает за servers.corp.adg.local?» - получал имя NS-сервера, пытался его резолвить, уходил в рекурсию и получал SERVFAIL. Добавили glue - часть запросов восстановилась.

Второе - SOA и serial. В delegated zone был SOA с нулевым serial number. Сервер решил, что зона пустая или устаревшая, и отказывался её отдавать с авторитетным ответом. Поправили serial до нормального числа, перезапустили службу DNS.

После обоих исправлений всё заработало.

Что вынесли

Делегирование в W2K DNS-мастере не создаёт glue автоматически - это надо делать руками. Вроде бы мелочь, но без неё делегирование работает только в части сценариев, а в другой части тихо падает.

SOA serial number - не декоративное поле. Если он нулевой или некорректный, сервер ведёт себя непредсказуемо. Стандартная практика - формат YYYYMMDDNN, где NN - порядковый номер изменений за день.

DHCP с авторизацией в домене - правильная вещь. Пока настраивали, один из сотрудников принёс ноутбук с включённым DHCP-сервером (раздавал адреса у себя дома). В изолированной сети W2K спокойно заблокировал бы его, авторизованный сервер имеет приоритет.

В целом переход с ручной прописки на DHCP - это то, что надо было сделать намного раньше. Администрирование адресов сразу стало прозрачным: видно, кому выдан какой адрес, когда истекает аренда. Конфликты адресов прекратились.

Ведение инфраструктуры вот такого масштаба - не самая сложная задача, но требует аккуратности в деталях. Если хочется заниматься своим бизнесом, а не разбираться в SOA serial и glue-записях, есть смысл отдать это на обслуживание специалистам.