Порядок разрешения имен windows

Картинка с сайта: habr.com

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат..

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

Дедушка NetBIOS

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

• регистрация и проверка сетевых имен;

• установление и разрыв соединений;

• связь с гарантированной доставкой информации;

• связь с негарантированной доставкой информации;

• поддержка управления и мониторинга драйвера и сетевой карты.

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.

Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

Картинка с сайта: habr.com

Пример работы кэша для разрешения имени узла «хр».

Картинка с сайта: habr.com

Что происходило при этом с точки зрения сниффера.

В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

Стандарт наших дней – DNS

DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

• если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

• сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

• после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

• затем сервер, который держит зону google.com уже выдает ответ.

Картинка с сайта: habr.com

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

Картинка с сайта: habr.com

На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Картинка с сайта: habr.com

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Порядок разрешения имен

Операционная система Windows пытается разрешить имена в следующем порядке:

• проверяет, не совпадает ли имя с локальным именем хоста;

• смотрит в кэш DNS распознавателя;

• если в кэше соответствие не найдено, идет запрос к серверу DNS;

• если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

• если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

• если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

• последняя попытка – система ищет записи в локальном файле lmhosts.

Для удобства проиллюстрирую алгоритм блок-схемой:

Картинка с сайта: habr.com

Алгоритм разрешения имен в Windows.

То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:

@echo off
echo %time%
ping hjfskhfjkshjfkshjkhfdsjk.com
echo %time%
ping xyz
echo %time%
pause

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Картинка с сайта: habr.com

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.

Active Directory и суффиксы

Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

При попытке запуска команды ping servername система проделает следующее:

• если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;

• если ответ будет отрицательный – система запросит servername.domain.com, на случай, если мы обращаемся к хосту родительского домена.

При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

Картинка с сайта: habr.com

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Картинка с сайта: habr.com

Суффиксы DNS и их порядок в выводе ipconfig /all.

Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

nslookup -dc2 ya.ru

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        4.4.8.8.in-addr.arpa, type = PTR, class = IN

    ANSWERS:
    ->  4.4.8.8.in-addr.arpa
        name = google-public-dns-b.google.com
        ttl = 86399 (23 hours 59 mins 59 secs)

------------
╤хЁтхЁ:  google-public-dns-b.google.com
Address:  8.8.4.4

------------
Got answer:

    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        ya.ru.subdomain.domain.com, type = A, class = IN

    ANSWERS:
    ->  ya.ru.subdomain.domain.com
        internet address = 66.96.162.92
        ttl = 599 (9 mins 59 secs)

------------
Не заслуживающий доверия ответ:

------------
Got answer:

    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        ya.ru.subdomain.domain.com, type = AAAA, class = IN

    AUTHORITY RECORDS:
    ->  domain.com
        ttl = 19 (19 secs)
        primary name server = ns-2022.awsdns-60.co.uk
        responsible mail addr = awsdns-hostmaster.amazon.com
        serial  = 1
        refresh = 7200 (2 hours)
        retry   = 900 (15 mins)
        expire  = 1209600 (14 days)
        default TTL = 86400 (1 day)

------------
╚ь :     ya.ru.subdomain.domain.com
Address:  66.96.162.92

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

ping ya.ru -n 1
Обмен пакетами с ya.ru [87.250.250.242] с 32 байтами данных:
Ответ от 87.250.250.242: число байт=32 время=170мс TTL=52

Это поведение иногда приводит в замешательство начинающих системных администраторов.

Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

Понимание DNS приходит с опытом

Недавно в нашей сети стали возникать блуждающие ошибки разрешения имен DNS. Отлавливать спорадические ошибки разрешения имен — занятие неблагодарное, тем более что с неполадками в DNS я не сталкивался достаточно давно и мои навыки слегка «запылились». Я бы предпочел сразиться с дюжиной других проблем, чем с этой. О существовании службы DNS легко забыть, пока она не начнет давать сбой, — все просто работает, как должно, — Internet, почтовый клиент, почтовый сервер, контроллеры домена. Прошло несколько лет с тех пор, как мне в последний раз довелось устранять проблемы с DNS, так что я расценил возникшие ошибки как знак свыше: пора вспомнить полезные навыки.

Поскольку DNS является основой нормального функционирования среды AD, а также тем звеном, которое соединяет в цепочку все сети в Internet, умение точно обнаруживать источник неполадок в DNS и устранять причину ошибки имеет огромное значение для сопровождения корпоративной сети. Сначала мы рассмотрим особенности решения проблем DNS, не связанные с AD, а затем посмотрим, что привносит AD.

Разрешение имен

Вся иерархия DNS строится от корневого домена (root domain). Корневой домен поддерживается 13 главными отдельными серверами, работа которых обеспечивается коммерческими, правительственными и образовательными учреждениями. В предельном случае эти корневые серверы участвуют в процессе разрешения всех публичных имен в Internet. Когда сетевой компьютер обращается к хосту с именем download.beta.example.com, в первую очередь он должен получить IP-адрес этого хоста. Этот процесс может потребовать до 10 различных запросов DNS, начиная с первого, с которым компьютер обращается к серверу, настроенному как сервер DNS. Стандартный процесс разрешения имен изображен на рис. 1.

Как видно из рисунка, локальный сервер DNS для определения соответствующего IP-адреса использует рекурсивные запросы — один из двух видов запросов DNS (второй тип называется итеративным). Каждый публичный сервер DNS, на который попадает запрос, либо выдает конечный результат (выполняет разрешение имени), если ему известен ответ, либо отправляет на связанный с ним вышестоящий сервер DNS, пытаясь определить неизвестный адрес. Поскольку корневой сервер DNS ничего не знает о конечных индивидуальных хостах в Internet, каковым является компьютер beta.example.com, он сообщает, что ничего не знает о подобном адресе, но советует опросить сервер, обслуживающий домен .com. По мере того как рекурсивный процесс продолжается, разрешение имени может произойти на одном из этапов, и результатом запроса будет либо искомый IP-адрес, либо отказ.

Описанная процедура разрешения имен может ввести пользователя в заблуждение: можно подумать, что корневые серверы доменов — это гигантские суперкомпьютеры, которые к тому же часто ломаются из-за чрезмерной нагрузки. В действительности же корневые серверы большой нагрузки не испытывают благодаря второму элементу процесса разрешения имен — кэшированию.

О кэшировании

Вернемся к изображенному на рис. 1 процессу разрешения имен, но на этот раз допустим, что локальный сервер DNS уже обращался к почтовому серверу для домена example.com, прежде чем обратиться к download.beta.example.com. В этом случае локальный сервер DNS уже обладает информацией о том, как находить ответственный за домен example.com сервер DNS (по крайней мере, он был таковым несколько минут назад). В этом случае можно обратиться непосредственно к серверу DNS домена example.com вместо того, чтобы вновь обращаться к серверу корневого домена. В этом случае шаги 2, 3, 4 и 5 в процессе разрешения имени окажутся необязательными, благодаря чему коммуникационный трафик снижается на 40%.

Кэширование выполняется на всех уровнях иерархической инфраструктуры DNS. Забегая вперед, скажу, что, если кто-нибудь еще в локальной сети обратится к тому же хосту download.beta.example.com, локальный сервер DNS сможет обработать запрос из локального кэша, поскольку нужный хост уже был недавно найден, и таким образом остаются только шаги 1 и 10 из схемы, приведенной на рис. 1. Это соответствует 80-процентному сокращению коммуникационного трафика.

Кэширование выполняют не только серверы DNS, но и клиенты, так что любая рабочая станция, которая недавно запрашивала разрешение имени хоста, будет некоторое время помнить его. Если приложение (Web-браузер, почтовый клиент) на хосте повторно запросит запись DNS, Windows будет использовать локальную копию вместо того, чтобы каждый раз направлять запрос DNS. Таким образом, коммуникационный трафик сокращается до нуля.

Эта иерархия кэширования, которая выполняется на каждом сервере и клиенте, вовлеченном в процесс разрешения имен DNS, поддерживает работоспособность DNS во всем Internet. Однако кэширование во время поиска и устранения неисправностей может и помешать.

Техника поиска и устранения ошибок

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

В кэше хранятся два основных типа записей — те, которые были найдены в результате запросов к серверу DNS, и те, что были предварительно загружены из файла \%systemroot% system32driversetchosts. Записи первого типа устаревают по истечении определенного интервала времени TTL (Time To Live), который задается в полученном от сервера DNS ответе.

Для просмотра содержимого кэша и определения оставшегося времени можно запустить из командной строки команду ipconfig /displaydns. В качестве примера я запустил поисковый запрос на www.google.com, а затем выполнил проверку ipconfig /displaydns. Как показано на экране 1, запись имеет значение TTL, равное 248 секундам. На момент выполнения запроса DNS время хранения информации TTL о домене google.com составляло 5 минут — что, впрочем, неудивительно для компании, которая имеет обширное и динамически изменяющееся присутствие в Internet. Более статичные организации обычно имеют более длительное значение TTL, например один день (86 400 секунд). В любом случае эта запись будет сохраняться в кэше в течение 5 минут, и, если обратиться к google.com повторно, Windows не будет направлять запрос к серверу DNS, а возьмет адрес из кэша.

Помимо кэширования положительных ответов, Windows также запоминает отрицательные ответы. Отрицательный ответ заключается в том, что сервер DNS считает себя ответственным за данный домен, но у него нет записи о хосте, требуемой в запросе. Хотя в отрицательных ответах не содержится сведений о TTL, Windows запоминает эти ответы на период времени от 5 до 15 минут, в зависимости от используемой версии Windows и дополнительных настроек. Более подробно об управлении кэшированием отрицательных ответов с помощью настроек реестра рассказано во врезке «Управление положительным и отрицательным кэшированием».

Те, кому пришлось столкнуться с проблемами разрешения имен в своей сети, могут очистить кэш DNS с помощью команды ipconfig /flushdns (и вовсе не обязательно править реестр). Очистка кэша DNS — это однократная операция, которая удаляет из памяти все сохраненные значения и позволяет начать все с чистого листа. Очистку кэша можно повторить в любой момент. При этом следует иметь в виду, что, если у вас имеется локальный сервер DNS, он, скорее всего, запоминает все адреса, к которым обращаются компьютеры сети. Чтобы очистить кэш DNS на серверах DNS, стоит воспользоваться оснасткой DNS консоли управления MMC. Для запуска в меню «Пуск» нужно выбрать «Программы», «Администрирование», DNS. Щелкните правой кнопкой мыши на имени сервера DNS и выберите Clear Cache.

Очистка кэша DNS — хорошее средство отладки для тех, кто занимается тестированием в сети чего-либо, связанного с разрешением имен, если нежелательные события произошли за последние 5-15 минут. Следует иметь в виду, что при очистке кэша DNS Windows автоматически сразу загружает в кэш адреса из файла \%systemroot%system32driversetchosts.

О хостах

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

Например, когда несколько серверов отвечают на одно и то же имя, а требуется, чтобы мой компьютер подключался к одному конкретному, я могу использовать файл hosts. Рассмотрим случай, когда несколько серверов доступа Microsoft Outlook Web Access используют общий адрес URL, который задается DNS. Если пользователи начинают жаловаться на возникновение случайных ошибок OWA, как определить, какой из серверов тому причиной? Файл hosts позволяет отказаться от услуг разрешения имен DNS и подставить требуемый адрес — для этого необходимо всего лишь внести в файл hosts значение, оно попадет в кэш и будет присутствовать там постоянно. Файл hosts имеет простой формат — в одной строке указываются IP-адрес и символьное имя. Служба разрешения имен обновляет значение в кэше автоматически при сохранении файла hosts, так что изменения вступают в силу немедленно.

Многосерверные/ многоадаптерные конфигурации

Рассмотрим подробнее схему, приведенную на рис. 2. Мы рассмотрели шаги, выполняемые в тех случаях, когда запрос может быть разрешен из локального кэша. Но если локальный кэш не позволяет выполнить разрешение запроса, то как дальше осуществляется процесс разрешения имени? Windows продолжает процесс разрешения имен, выдавая рекурсивные запросы DNS к серверам, указанным в качестве предпочтительных (настройка сервера DNS выполняется в параметрах протокола TCP/IP для каждого сетевого адаптера, как показано на экране 2). Если Windows не получает никакого ответа от предпочтительного сервера DNS в течение секунды, этот же запрос передается по остальным сетевым интерфейсам с интервалом ожидания 2 секунды. Если ответа по-прежнему нет, Windows выполняет три повторные попытки получить ответ на запрос. Каждый следующий раз устанавливается более длительный интервал ожидания (2, 4 и 8 секунд соответственно), после чего выполняется обращение ко всем остальным серверам DNS по всем имеющимся сетевым интерфейсам. Общее время разрешения адреса DNS не должно превышать 17 секунд.

Каков механизм выбора предпочтительного и приемлемого сетевого адаптера (в Microsoft используют термин under consideration — «рассматриваемый»). Техническая документация Microsoft дает расплывчатые ответы в вопросах разрешения имен. Например, если все серверы DNS для определенного адаптера были опрошены и ни один из них не ответил, данный адаптер исключается из рассмотрения на 30 секунд. Можно предположить, что при этом адаптер временно исключается из категории «приемлемый» на указанный интервал времени, хотя в документации об этом не говорится. Кроме того, в документации Microsoft указано, что служба разрешения имен DNS запоминает время отклика серверов DNS и может выбирать предпочтительный сервер в зависимости от скорости получения ответа на запросы, — видимо, такой же подход используется и для определения предпочтительного адаптера.

Утверждение Microsoft о том, что служба разрешения имен может изменять порядок следования предпочтительных серверов DNS, противоречит настройкам, которые можно найти в расширенных окнах настроек DNS для сетевых адаптеров, где порядок следования определяется администратором при задании конфигурации. В большом количестве документов Microsoft дана другая информация. Поэтому я не очень доверяю сведениям о том, в каком порядке служба разрешения имен обращается к серверам DNS при разрешении имен. Когда мне приходится заниматься поиском и устранением неисправностей, я пользуюсь инструментами типа Network Grep (Ngrep) и WinDump для проверки отправляемых компьютером запросов DNS и серверов, которым эти запросы адресованы.

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

Nslookup

Теперь, разобрав принципы выполнения запросов DNS и то, каким образом служба разрешения имен DNS направляет запросы DNS через установленные в компьютере сетевые интерфейсы, можно задействовать утилиту командной строки Nslookup, которая, безусловно, является одним из основных инструментов решения проблем с DNS и поиска и устранения неисправностей.

Nslookup может запускаться в неинтерактивном режиме и позволяет тестировать поиск и разрешение имен хостов с использованием стандартной службы разрешения имен Windows. Пример:

nslookup www.windowsitpro.com

С другой стороны, можно направить запрос DNS на конкретный сервер вместо тех, которые указаны на локальном компьютере. Для этого достаточно добавить в конце командной строки адрес данного сервера DNS:

nslookup www.windowsitpro.com 10.0.0.1

Это понадобится, если нужно убедиться, что получаемые ответы исходят именно от данного сервера DNS.

Чтобы более детально вникнуть в процесс разрешения имен, можно запустить Nslookup в интерактивном режиме, который позволяет выбирать сервер, тип запроса (рекурсивный или итеративный) и детализацию отладочной информации. Рассмотрим для примера несколько сценариев обнаружения неисправностей.

Как уже упоминалось, в некоторых случаях процесс разрешения имен вынужден пройти всю цепочку до корневых серверов доменов Internet, если ни один другой сервер по пути прохождения запроса не располагает кэшированной информацией, имеющей заданный интервал TTL. Можно выполнить полное прохождение цепочки, чтобы определить, где процесс прерывается. Для воспроизведения этого процесса с помощью Nslookup можно вызвать итеративный (нерекурсивный) запрос поиска для целевого домена, указав при этом один из корневых доменных серверов (список корневых доменов приведен в таблице) в качестве целевого сервера, а затем вручную проследовать по каждому направлению, которое возвращается до получения итогового результата.

Я выполнил поиск для полного доменного имени компьютера (FQDN) www.windowsitpro.com, настроив Nslookup для использования итеративных запросов. В приглашении я ввел параметр Set Norecurse, затем указал корневой сервер с помощью параметра Server и выполнил запрос. Следуя по адресам серверов, я проследил всю цепочку, указывая вручную целевой сервер при каждой итерации. Такой способ дает значительно больше информации для поиска и устранения неисправностей, чем выполнение стандартного запроса к локальному серверу DNS и анализ данных, которые приходят в ответ.

Если для решения задачи не требуется выполнять полный итеративный опрос, а просто нужна более подробная информация о прохождении запросов и возвращаемой информации, можно задействовать ключи Set Debug или Set D2 для отображения отладочной информации о выполнении запроса DNS. На экране 3 приведен результат исполнения примера запроса разрешения имени www.windowsitpro.com. Аналогично ключ Set Type позволяет использовать Nslookup для быстрого поиска определенных типов записей в домене по их типу. Для поиска почтовых серверов требуется указать ключ MX (Mail Exchange), а для серверов имен — NS (Name Server).

Добавим немного AD

Теперь, когда мы познакомились с концепциями кэширования, последовательного и рекурсивного выполнения запросов, а также с приемами диагностики проблем разрешения имен в Internet, не составит большого труда разобраться с теми особенностями, которые привносит AD. Интеграция DNS и AD происходит на двух уровнях: во-первых, DNS является основным механизмом, с помощью которого компьютеры в сети находят другие хосты в среде AD, во-вторых, данные DNS — список существующих хостов и их адреса IP — реплицируются между серверами DNS через механизм репликации AD. Механизмы репликации AD обсуждались на страницах журнала достаточно подробно, так что рассмотрим дополнительную информацию, которая содержится в записях DNS в среде AD.

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

Например, эти специальные сетевые адаптеры могут быть зарегистрированы с адресами IP в DNS, в то время как было нежелательно, чтобы эти сетевые адреса выдавались в качестве возможных вариантов при разрешении имен. Если это все-таки случилось, можно отменить регистрацию сетевого интерфейса. Для этого необходимо выполнить редактирование дополнительных свойств DNS для данного интерфейса и снять флажок Register this connection?s address in DNS («Зарегистрировать это соединение в DNS»), как показано на экране 4. В противном случае Windows обязательно попытается зарегистрировать в DNS все имеющиеся сетевые интерфейсы.

Помимо автоматической регистрации этих записей хостов (записи типа А), Windows выполняет для контроллеров доменов регистрацию дополнительных записей сервера (записи SRV). Запись SRV определяет тип участия компьютера в AD при обработке специальных задач аутентификации. Записи SRV не являются уникальными для AD, напротив, это стандартный тип записей DNS, определяющий зарегистрированные в домене службы, хосты, на которых эти службы могут быть найдены, используемые порты и протоколы. Аналогично тому, как записи почтовой службы MX указывают, что служба SMTP может быть найдена на определенном порту (т. е. порт 25) на данном сервере, записи SRV предоставляют ссылку для любого типа служб на любой системе. Например, запись SRV, определяющая хост example.com как Web-сервер, может иметь следующий вид:

_http._tcp.example.com SRV 0 0 80
 www.example.com

Рассматривая этот пример, можно сделать следующие заключения: служба TCP, известная как HTTP, доступна в домене example.com; она доступна по порту 80 для хоста с именем www.example.com. В среде AD контроллер домена регистрирует четыре типа записей SRV на серверах DNS, на работу с которыми он настроен:

_ldap._tcp.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.example.com
SRV 0 0 88 dc.example.com
_ldap._tcp.dc._msdcs.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.dc._msdcs.example.com
SRV 0 0 88 dc.example.com

Эти записи позволяют клиентам AD определять, где найти службы LDAP и Kerberos, которые необходимы в домене example.com для обнаружения других ресурсов AD и аутентификации доступа к этим ресурсам. Эти четыре примера записей SRV сообщают зависящим от AD клиентам о контроллере домена dc.example.com (гипотетический контроллер домена example.com), который будет использоваться для всех видов аутентификации.

С помощью оснастки DNS MMC следует сделать эти записи доступными для серверов DNS. Необходимо также иметь возможность просматривать их с клиента с помощью Nslookup.

Знания — в жизнь

После применения Nslookup мне удалось быстро определить источник проблемы. Дело было в ошибке кэширования, связанной с ответами моего провайдера на некоторые запросы DNS. Для определения причины неполадок мне пришлось выполнить итеративный процесс разрешения адреса собственного компьютера. После этого я смог быстро настроить альтернативное разрешение внешних имен DNS, а провайдер занялся устранением собственных недоработок. Проблема была решена быстро, и мои клиенты снова смогли пользоваться полнофункциональным разрешением имен. Знание принципов работы DNS в сочетании с удобными средствами обнаружения ошибок позволяют без труда устранять большинство проблем с DNS.

Дуглас Тумбс — Редактор журнала Windows IT Pro. help@toombs.us

Ошибка маленькая — проблемы большие

Администратор сети Скотт Рассел расследует мистическую ошибку DNS

«Я дважды переустановил сервер DNS в соответствии с имеющейся документацией, но это не помогло. В конце концов я связался с провайдером и узнал, что головная компания поменяла записи DNS и MX на всех серверах…»

Когда в 8 вечера Скотту Расселу позвонил ИТ-администратор с прежнего места работы, он понял, что это не просто дань вежливости. Два дня назад у них в компании перестало работать подключение к Internet. Сотрудники не могли пользоваться электронной почтой через корпоративный сервер Exchange и регистрироваться в сети Windows 2000 Server. Специалисты по ИТ испробовали все, что могли, но безуспешно. Скотт согласился помочь, и скоро выяснилось, что все дело в ошибке настройки DNS. Рассел работает в области ИТ более 10 лет, в настоящее время он является администратором сети в канадской компании ABC Window Company. Старший редактор Windows IT Pro Энн Грабб побеседовала со Скоттом Расселом о том, как ему удалось определить источник проблемы и восстановить работоспособность компании.

ИТ-администратор с вашей предыдущей работы попросил помочь устранить проблему, которую они не могли решить два дня. В чем же было дело?

Да, у них ничего не работало: они не могли регистрироваться в сети, пользоваться Internet и электронной почтой. Когда я был там сетевым администратором, мы создали два домена — внешний домен company.com для Web и SMTP и внутренний домен company.net. Мы не регистрировали домен .net, поскольку он был внутренним. Наш провайдер обеспечивал работу Web-сайта компании и держал у себя внешние записи DNS и MX.

Прибыв на место, я в первую очередь проверил настройки DNS, дабы убедиться, что все в порядке. В компании имеется три контроллера домена и два сервера DNS, которые я настраивал, когда работал сетевым администратором — там использовалась служба Windows DNS, интегрированная со службой каталога AD. Я дважды переустановил сервер DNS по той документации, которую подготовил перед уходом. Это был довольно трудоемкий процесс.

Надо было разобраться, почему DNS не мог разрешить IP-адрес контроллера домена для локального домена company.net. Мы задействовали утилиту Traceroute для адреса IP, который мы использовали, как нам казалось, и выяснилось, что в результате возвращается совершенно другой внешний IP-адрес. У нас не было никаких предположений относительно того, что происходит, хотя адрес был из того же диапазона, что и наш. Первым делом мы подумали о внешнем вторжении в сеть.

Как же вы определили, кому принадлежит этот IP-адрес?

Ну, во-первых, я зашел на сайт поддержки Microsoft (http://www.support.microsoft.com) и провел там почти два с половиной часа. Пока я изучал материалы сайта, мне пришло в голову, что кто-нибудь мог просто зарегистрировать это доменное имя. Тогда я решил позвонить провайдеру. Через три часа мне сообщили, что неизвестный адрес принадлежит их материнской компании. В этот момент выяснилось, что материнская компания зарегистрировала доменное имя, совпадающее с нашим локальным доменом .net.

Обратившись к ним, мы убедились, что так оно и есть. Они зарегистрировали домен .net и изменили все записи DNS, включая и MX, ничего не сообщив своим пользователям.

Но когда вы обнаружили, что имя внутреннего домена зарегистрировано материнской компанией провайдера, вам необходимо было избежать переименования своего домена. Как вы вышли из положения?

Сначала я запросил у провайдера новый IP-адрес и информацию о зонах для их DNS. Затем потребовалось зарегистрировать нашу запись DNS в качестве вторичного сервера DNS для их сервера DNS, чтобы мы смогли зарегистрироваться в системе и выполнить необходимые изменения. Я добавил вторичную зону в нашу запись DNS и настроил их DNS в качестве вторичного DNS у нас, так что наш сервер DNS смог распознавать внешние имена company.com корректно.

С этого момента у нас появилась возможность работать с Internet. Затем нам потребовалось реплицировать вторичную зону DNS в AD. Когда мы это сделали, все стало работать нормально, пользователи получили возможность регистрироваться на сервере и работать с электронной почтой.

Какие рекомендации вы могли бы дать коллегам по цеху с учетом уроков, извлеченных из этой истории?

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

И конечно, я хорошо запомнил свою ошибку с использованием домена .net. Теперь для всех внутренних настроек DNS я использую суффикс .local.

Энн Грабб — Старший редактор в Windows IT Pro. Она имеем более чем двадцатилетний опыт работы, является автором и редактором статей, книг и других материалов по компьютерной и юридической тематике. agrubb@windowsitpro.com

Управление положительным и отрицательным кэшированием

Кэширование в Windows выполняется в соответствии с установленными по умолчанию значениями, которые могут варьироваться в зависимости от используемой версии Windows и дополнительных настроек. Для управления кэшированием применяются два параметра реестра.

Раздел HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServices DNSCacheParameters содержит параметры, управляющие продолжительностью хранения в кэше положительных и отрицательных ответов. Эти значения в версиях Windows Server 2003, Windows XP и Windows 2000 слегка отличаются.

Для положительного кэширования в Windows 2000 этот параметр называется MaxCacheEntryTtlLimit, в Window XP и 2003 он называется MaxCacheTtl. Оба параметра указывают максимальный срок, в течение которого положительные ответы могут храниться в кэше. Если этот параметр определен, по умолчанию его значение равно 86400 секундам (1 день). Это значение имеет преимущество перед всеми возможными значениями TTL, которые превышают данное значение. Поэтому, если оставить значение по умолчанию, Windows будет сохранять положительные ответы не более одного дня, даже если указанное значение TTL равно, скажем, пяти дням. Установив значение параметра равным одной секунде, можно практически предотвратить кэширование положительных ответов DNS.

Кэширование отрицательных ответов управляется параметром NegativeCacheTime в Windows 2000, а в Windows XP и 2003 — MaxNegativeCacheTtl. Значение по умолчанию составляет 300 секунд (5 минут) для Windows 2000 и 900 секунд (15 минут) для XP и 2003. Отрицательные ответы, возвращаемые сервером DNS, будут сохраняться в кэше именно такое время, так что, если после первой неудачной попытки сервер DNS получит нормальное разрешение имени, он все равно будет возвращать отказ на этот адрес до того момента, пока не закончится TTL отрицательного ответа. Если вы подключаете новые компьютеры, отрицательное кэширование действительно может вызвать проблемы в случае попытки найти компьютер до того, как запись о его присутствии будет распространена в сети.

Более подробные сведения об этих процедурах можно найти в статьях базы знаний Microsoft «How to Disable Client-Side DNS Caching in Windows 2000» (http://support.microsoft.com/default.aspx?scid=kb;en-us;245437) и «Disable Client-Side DNS Caching in Windows XP and Windows Server 2003» (http://support.microsoft.com/default.aspx?scid=kb;en-us;318803).

Инструменты для поиска и устранения ошибок DNS

В статье, посвященной поиску и устранению неисправностей в работе службы DNS, невозможно обойти вниманием сайт DNSstuff.com (http://www.dnsstuff.com). Этот сайт разработан и поддерживается Р. Скотт Пери. Здесь бесплатно предоставляются средства для работы с DNS, IP-адресами, доменами и т.д., предназначенные для простого и удобного поиска и устранения неисправностей с использованием Web-служб. Эти инструменты позволяют выполнить разрешение имен в IP-адреса, обратный поиск (reverse lookup), поиск WHOIS, а также проверку выбранных адресов IP на вхождение в базу адресов — известных источников спама. Я считаю DNSstuff.com чрезвычайно удобным инструментом для отладки DNS у клиентов.

Примечательно, что предлагаемый этими средствами вариант поиска хоста позволяет автоматически выполнить итеративный запрос DNS, начиная с корневых серверов, и пройти весь путь до конечного имени хоста с использованием удобного и красивого Web-интерфейса. Это избавляет от необходимости выполнять данную процедуру вручную с помощью Nslookup и позволяет продемонстрировать клиентам результаты в гораздо более удобной и понятной форме. Вдобавок DNSstuff.com содержит функцию опроса основных Internet-провайдеров для проверки, не выдают ли они различные кэшированные ответы на один и тот же запрос DNS.

С сервисом доменных имен уже все знакомы давным давно. Это одна из самых “полезных” служб, назначение которой даже для обычного пользователя более чем очевидно. Мало кто хорошо разбирается в том, как DNS реально работает и что стоит за “простым” разрешением имен из имени в ip-адрес (и не только). Должен признаться, что я и сам понимаю не все нюансы, поскольку по специфике своей работы каждый день с DNS не сталкиваюсь (вписывать серверы DNS в сетевые настройки не считается). Кроме того, даже если удается в чем-то разобраться, все очень быстро забывается. Ведь в корпоративной сети DNS одна их тех служб, которые настроил и забыл.

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

Общие сведения

Для начала необходимо все разложить по полочкам ¹:

“Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

• Всего множества доменных имен (domain name space)
• Серверов доменных имен (domain name servers)
• Клиенты DNS (Resolver-ы)”

Структура множества доменных имен представляет из себя древовидную иерархию. Чтобы не усложнять изначально достаточно простую вещь, я подобрал наиболее подходящую картинку с описанием иерархии доменных имен ²:

Классификация доменных имен также не должна вызывать сложностей в понимании, но на удивление в интернете практически не найти нормальные иллюстрации. Мне под руки попалась только одна ³:

Вообще на этом канале ⁴ огромное количество уроков, которые посвящены именно DNS. Однозначно советую к просмотру. Хоть и описание типов dns-серверов есть и на Википедии ⁵, оно там плоское и только зря сводит с толку.

Вопросов кто такие dns-клиенты возникать не должно.

Если говорить про авторитативные и неавторитативные серверы, то их отличие состоит в том, что в первом случае сервер отвечает за зону, а во втором – нет. То есть неавторитативные серверы выступают в большинстве случаев только как кэширующие и могут только копировать эту зону. Это хорошо понятно из иллюстрации выше.

Есть несколько типов авторитативных dns-серверов: primary master, master, slave. Четкие различия есть только между primary master и slave. Суть в том, что в первом случае сервер стоит во главе иерархии, на нем можно производить изменения описания зоны и этот сервер никогда не будет копировать эту зону с других серверов. Slave-серверы наоборот являются лишь вторичными и копируют зону с primary master; их главная задача – балансировка нагрузки, резервирование. Определение типа серверов master для меня несколько затруднительно. На многих источниках эти серверы также называют основными:

“Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера.”

… но, с другой стороны, этому противоречит определение primary-master даже с тех же источников:

“Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master.”

То есть по факту не на всех master-серверах можно вносить изменения в описание зоны, а только на одном единственном master-сервере, который называется primary master. В таком случае реально существует только два “статичных” типа сервера – primary master и slave. Роль master может быть у сервера лишь какой-то определенный короткий промежуток времени – когда один slave-сервер (пусть он будет назван Сервер 1) копирует информацию с другого slave-сервера (Сервер 2). В этом случае Сервер 2 имеет право называться master-сервером для Сервер 1, но это справедливо только для конкретно взятого процесса копирования зоны. Когда же Сервер 2 будет копировать описание зоны с единственного primary master, он снова будет являться slave-сервером. Это подтверждает иллюстрация с nic.ru ⁶:

Вот таки размышления. Конечно все эти определения скорее запутывают, чем помогают разобраться. Надо просто иметь в виду, что есть primary master и он стоит вверху иерархии и есть все остальные. Стоит добавить, что серверы всех трех типов будут являться авторитативными, то есть ответственными за зону.

Во главе всей иерархии доменных имен стоят серверы, обслуживающие корневую зону, они называются корневыми серверами. Именно к ним в первую очередь обращаются все другие dns-серверы, если у них нет данных о каком-либо доменном имени. В иерархии доменных имен на первом рисунке в статье они находятся на уровне “.“.

Прежде чем перейти к описанию типов запросов нужно обратить внимание на ещё один важный момент – разницу между зоной и доменом. Вопрос затрагивается в публикации на Хабре ⁷:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

На мой взгляд более точно и понятно сказано в статье на nic.ru, которая упоминалась в самом начале:

Домен – это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Зона – это “зона ответственности” конкретного сервера доменных имен, т.е. понятие домена шире, чем понятие зоны. Если домен разбивается на поддомены, то у каждого из них может появиться свой сервер. При этом зоной ответственности сервера более высокого уровня будет только та часть описания домена, которая не делегирована другим серверам. Разбиение домена на поддомены и организация сервера для каждого из них называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

Запросы к dns-серверам бывают двух типов – рекурсивный и нерекурсивный (итеративный). Наиболее подробно принцип работы описывается ^{8 9} на упомянутом выше канале Youtube. При рекурсивном запросе клиент обращается к предпочитаемому dns-серверу и тот, если не знает ответа, начинает по очереди опрашивать ответственных за зоны серверы, начиная с корневых и далее опускаясь ниже по иерархии. Исчерпывающее объяснение работы рекурсивного запроса дается в статье ¹⁰ на oszone.ru. Итеративный запрос менее распространен. В нем клиент сам по очереди опрашивает dns-серверы, начиная с корневых и т.д.. Разумеется если не найдет результаты запроса в своем кэше.

Наглядно рекурсивный ^{11 12} запрос выглядит так:

а нерекурсивный ¹³:

На этом обзор основных принципов работы dns закончен. Рассмотрение типов записей dns, а также механизмов работы обратного разрешения имен (ip-адрес по dns-имени) я в рамках этой статьи я затрагивать не планировал, хотя конечно же это очень интересные темы.

Роль DNS на Windows Server

Настройка роли dns на Windows Server представляет из себя достаточно простую задачу, как и многие другие – добавил роль в диспетчере сервера, запустил визарда и все настроил. Тем не менее встречаются парадоксальные ситуации и иногда слышишь рассказы как некоторые “админы” добавляют одни и те же учетные записи пользователей по очереди на каждом контроллере домена, не имея понятия о репликации. И ведь самое страшное, что у них это получается! То есть можно сделать вывод, что контроллеры домена хоть и поддерживают один и тот же домен, но фактически друг о друге ничего не знают (иначе учетку с аналогичным именем создать бы не получилось). А ведь это может являться следствием неправильной настройки роли DNS, которая обычно всегда идет бок о бок с AD DS.

Этот раздел будет посвящен обзору лучших практик по настройке роли DNS (интегрированной в AD) на Windows Server 2012 R2, но большинство советов актуальны и для предыдущих версий ОС. Тем не менее не стоит забывать про улучшения, которые добавляются в каждой новой версии и 2012 R2 не исключение ^{14 15}.

Я подразумеваю, что нет никакого смысла повторять, что в каждом домене должно быть минимум два контроллера домена. Это необходимо для отказоустойчивости. Собственный ip-адрес сервера должен быть обязательно статическим ¹⁶.

Собственно сами рекомендации:

1) “If multiple DCs are configured as DNS servers, they should be configured to use each other for resolution first and themselves second” ¹⁷.

Суть в том, что, во избежание проблем с репликацией, в списке первичных dns-серверов на каждом контроллере домена первыми должны быть указаны партнеры по репликации, то есть другие контроллеры домена. Собственный адрес отдельно взятого сервера должен быть указан самым последним ¹⁸ в его списке dns-серверов. Для увеличения производительности последним в списке используйте loopback-адрес 127.0.0.1 ¹⁹ как собственный адрес сервера (но не реальный сетевой адрес адаптера), хоть и это иногда может вызывать небольшие проблемы ²⁰.

2) На клиентских системах должны использоваться только локальные dns-серверы, но никак не публичные.

В противном случае у вас могут возникнуть проблемы ²¹ с разрешением внутренних имен, хотя выход наружу будет доступен. Тем не менее в корпоративной сети у меня доступ наружу по dns портам разрешен только контроллерам домена и серверам Exchange.

Позаботьтесь о том, чтобы ваш dhcp-сервер выдавал клиентам настройки со всеми имеющимися у вас адресами серверов dns. Их может быть два, а может быть и больше, все зависит от конкретной топологии. Если у вас структура AD с множеством сайтов, то логично, чтобы по порядку сначала шли серверы сайта, в котором этот пк находится и уже только потом выдавались адреса dns-серверов других сайтов ²².

3) Если у вас домен AD, то используйте только интегрированную с AD роль DNS (AD-integrated). Прибавится достаточно много плюсов в плане безопасности, производительности и отказоустойчивости ²³.

Если говорить про отказоустойчивость, то у вас не будет единой точки отказа в виде одного primary master-сервера для вашей зоны dns (если этот сервер выйдет из строя и не будет сразу восстановлен или заменен, запросы клиентов на изменение записей обрабатываться не будут. Не то что бы это очень большая проблема для статичного парка пк, но приятного мало). К тому же администраторам не придется возиться с двумя разными схемами репликации – dns и ad ds; у более простых и понятных схем надежность возрастает в разы.

Производительность всей инфраструктуры увеличивается, поскольку все партнеры по репликации (контроллеры домена) имеют одинаковый вес и нет master- и slave- серверов. То есть, если бы запрос поступил к slave-серверу классического dns, то он должен был бы обратиться к мастеру для инициирования процесса обновления. При интегрированной в ad dns каждый контроллер домена может писать изменения в базу dns и уже дальше неспеша реплицировать их на другие контроллеры. К тому же сам по себе механизм репликации ad ds значительно быстрее.

Безопасность увеличивается благодаря защищенным динамическим обновлениям ²⁴. О DNSSEC речь тут не идет, это общая технология, хотя и в Windows есть её реализация ^{25 26}.

Из лучших практик это наверно все. Есть некоторые размышления ²⁷ касательно того, что лучше ²⁸ использовать – корневые подсказки или серверы пересылки, но это скорее личное дело админа, чем какая-то устоявшаяся практика. Помните, что к корневым серверам ваш dns-сервер выполняет итеративные запросы, а к серверам пересылки – рекурсивные, являясь по отношению к ним клиентом. Root hints сконфигурированы изначально, т.к. они едины для всей сети интернет, а forwarder’ы придется указать вручную. Единственное, что можно отметить – не указывайте в серверах пересылки публичные серверы; пусть лучше это будут dns-ресурсы вашего провайдера.

Есть также рекомендации ^{29 30 31 32}(обязательно к прочтению) касательно автоматической очистке записей dns. В этой статье я их подробно не рассматриваю, поскольку автоматическая очистка записей по умолчанию отключена. На деле процесс настройки очень простой, но имеет колоссальные последствия ³³ для инфраструктуры в том случае, если вы не понимаете что конкретно делаете и к чему это может привести.