Шаги настройки DNS-суффикса, необходимые, когда концентратор или клиент не может обнаружить корпоративный сервер для приложения Intel Unite®
Тип материала Поиск и устранение неисправностей
Идентификатор статьи 000027773
Последняя редакция 05.04.2018
Какова цель этой процедуры?
Вы можете принудительно задействовать DNS-суффикс и тестировать приложение Intel Unite® в режиме предприятия. Не принимайте эти действия для сетевой среды, которая настроена правильно.
Концентратор или клиенты нахождения корпоративного сервера с помощью службы DNS во время автоматического поиска для корпоративного сервера. Приложение Intel Unite® требует, чтобы DNS-суффикс был распознан как DNS-суффикс, специфичный для подключения.
Как добавить DNS-суффикс для подключения вручную с помощью Windows® 10
- Убедитесь, что на адаптере Ethernet не назначен DNS-суффикс, специфичный для подключения:
Добавьте DNS-суффикс, специфичный для подключения, настроив сетевой адаптер. Перейти к панели управления, ПоискСеть и Интернет, выберитеЦентр сети и общего доступа, а затем выберитеИзменение параметров адаптерав меню слева.
Каков порядок просмотра DNS серверов в Windows 7 / 8 / 8.1?
Дано: клиентские машины под управлением windows 7 / 8 / 8.1
openvpn клиент (последний с community сайта)
При подключении к Internet присваивается два DNS-сервера: 8.8.8.8 и 8.8.4.4. Затем при подключении по OpenVPN (tap интерфейс, если это важно) от vpn-сервера «падают» ещё два DNS-сервера: 192.168.50.10 и 192.168.70.10.
Из вывода ipconfig /all видно что первые два «висят» на eth, а вторые два на tap.
Как заставить клиента DNS на компьютере просматривать DNS-сервера в следующем порядке:
192.168.50.10
192.168.70.10
8.8.8.8
8.8.4.4
Настройка разрешения имен на DNS-клиентах
Способ настройки разрешения имен на DNS-клиентов зависит от конфигурации сети. Если в ней применяется DHCP, настройка DNS осуществляется при помощи параметров DHCP-сервера. Если на компьютерах используются статические ІР-адреса или вы хотите особо настроить DNS для отдельного пользователя или системы, придется настроить DNS вручную.
Параметры DNS задаются на вкладке DNS диалогового окна Дополнительные параметры TCP/IP (Advanced TCP/IP Settings). Чтобы открыть это окно, выполните следующие действия:
1. В окне Центр управления сетями и общим доступом (Network And Sharing Center) щелкните ссылку Управление сетевыми подключениями (Manage Network Connections). В окне Сетевые подключения (Network Connections) щелкните правой кнопкой нужное подключение и выберите команду Свойства (Properties).
2. Дважды щелкните протокол, соответствующий типу настраиваемого ІР-адреса — TCP/IPv6 или TCP/IPv4.
3. Если вы используете DHCP и хотите, чтобы адрес DNS-сервера был задан посредством DHCP, установите переключатель Получить адрес DNS-сервера автоматически (Obtain DNS Server Address Automatically). В противном случае установите переключатель Использовать следующие адреса DNS-серверов (Use The Following DNS Server Addresses), а затем введите адреса основного и дополнительного DNS-серверов в соответствующих полях.
4. Щелкните кнопку Дополнительно (Advanced), чтобы открыть диалоговое окно Дополнительные параметры TCP/IP (Advanced TCP/IP Settings). Перейдите на вкладку DNS. Далее описаны параметры вкладки DNS:
• Адреса DNS-серверов, в порядке использования Укажите ІР-адрес каждого DNS-сервера, используемого для разрешения доменных имен. Чтобы добавить ІР-адрес сервера в список, щелкните Добавить (Add). Щелкните Удалить (Remove), чтобы удалить адрес выделенного сервера из списка. Для редактирования выделенной записи щелкните Изменить (Edit). Если вы указываете несколько серверов DNS, их приоритет определяется очередностью в списке. Если первый сервер не может ответить на запрос о разрешении имени хоста, запрос посылается на следующий DNS-сервер и т. д. Чтобы изменить положение сервера в списке, выделите его и воспользуйтесь кнопками со стрелками вверх и вниз.
• Дописывать основной DNS-суффикс и суффикс подключения (Append Primary And Connection Specific DNS Suffixes) Обычно по умолчанию этот переключатель установлен. Он применяется для разрешения неполных имен компьютеров в основном домене. Допустим, вы обращаетесь к компьютеру Pavel в родительском домене logi.cc. Для разрешения имя компьютера будет автоматически дополнено суффиксом DNS — pavel.logi.cc. Если в основном домене компьютера с таким именем нет, запрос не выполняется. Основной домен задается на вкладке Имя компьютера (Computer Name) диалогового окна Свойства системы (System Properties).
• Дописывать родительские суффиксы основного DNS-суффикса (Append Parent Suffixes Of The Primary DNS Suffix) По умолчанию Этот флажок установлен. Он используется для разрешения неполных имен компьютеров в иерархии родительских и дочерних доменов. В случае неудачного запроса в ближайшем родительском домене, для попытки разрешения запроса используется суффикс родительского домена более высокого уровня. Этот процесс продолжается, пока не будет достигнута вершима иерархии доменов DNS. Допустим, в запросе указано имя компьютера Pavel в родительском домене dev.logi.cc. Сначала DNS пытается разрешить имя компьютера pavel.dev.logi.cc, а потом, в случае неудачи, пытается разрешить имя pavel.logi.cc
• Дописывать следующие DNS-суффиксы (по порядку) (Append These DNS Suffixes (In Order)) Установите этот переключатель, чтобы задать использование особых DNS-суффиксов вместо имени родительского домена. Щелкните Добавить (Add), чтобы добавить суффикс домена в список. Щелкните Удалить (Remove), чтобы удалить выделенный суффикс домена из списка. Для редактирования выделенной записи щелкните Изменить (Edit). Вы можете указать несколько суффиксов домена. Если первый суффикс не позволяет разрешить имя, DNS применяет следующий суффикс из списка. В случае неудачи берется следующий суффикс и так далее. Чтобы изменить очередность суффиксов домена, выберите нужный суффикс и измените его положение кнопками со стрелками вверх и вниз.
• DNS-суффикс подключения (DNS Suffix For This Connection) В этом поле задастся DNS-суффикс подключения, перекрывающий DNS-имена, уже настроенные на использование с данным подключением.
• Зарегистрировать адреса этого подключения в DNS (Register This Connection’s Addresses In DNS) Установите этот флажок, если хотите, чтобы все ІР-адреса данного подключения регистрировались в DNS с FQDN-именами компьютеров. Этот флажок по умолчанию установлен.
• Использовать DNS-суффикс подключения при регистрации в DNS (Use This Connection’s DNS Suffix In DNS Registration) Установите этот флажок, если хотите, чтобы все ІР-адреса для данного подключения регистрировались в DNS родительского домена.
источники:
http://qna.habr.com/q/193897
http://logi.cc/nastrojka-razresheniya-imen-na-dns-klientax/
|
|
В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат..
Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.
Дедушка NetBIOS
NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:
-
регистрация и проверка сетевых имен;
-
установление и разрыв соединений;
-
связь с гарантированной доставкой информации;
-
связь с негарантированной доставкой информации;
- поддержка управления и мониторинга драйвера и сетевой карты.
В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.
Небольшая памятка о сути широковещательных запросов.
Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.
Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255
Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.
Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.
Пример работы кэша для разрешения имени узла «хр».
Что происходило при этом с точки зрения сниффера.
В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.
В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.
В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%System32driversetclmhost.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 уже выдает ответ.
Наглядная схема прохождения запроса DNS.
Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.
Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.
DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.
Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%System32driversetchosts.
В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.
На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.
При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 72008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTDnsClientDnsPolicyConfig или групповыми политиками.
Настройка политики разрешения имен через GPO.
При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.
Порядок разрешения имен
Операционная система Windows пытается разрешить имена в следующем порядке:
-
проверяет, не совпадает ли имя с локальным именем хоста;
-
смотрит в кэш DNS распознавателя;
-
если в кэше соответствие не найдено, идет запрос к серверу DNS;
-
если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;
-
если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;
-
если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;
- последняя попытка – система ищет записи в локальном файле lmhosts.
Для удобства проиллюстрирую алгоритм блок-схемой:
Алгоритм разрешения имен в Windows.
То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:
@echo off
echo %time%
ping hjfskhfjkshjfkshjkhfdsjk.com
echo %time%
ping xyz
echo %time%
pause
Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.
Сниффер показывает запросы 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 суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.
Настройка добавления суффиксов DNS через групповые политики.
Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCPIP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.
Суффиксы 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-курьезы из собственной практики – поделитесь в комментариях.
В данной статье предпринята попытка выйти за пределы структуры единственного леса/единственного домена AD, в которой конфигурация DNS сравнительно проста, и исследовать работу DNS в более сложной архитектуре AD. Одновременно рассматривается несколько новых концепций DNS, реализованных в Windows Server 2008 R2
Служба DNS, обеспечивающая преобразование доменных имен в IP-адреса, — не просто система распознавания имен для всего Интернета. Это критически важный компонент Active Directory (AD), необходимый для обнаружения сетевых ресурсов. Но несмотря на повсеместный переход с системы WINS на DNS в сетях Windows в последнее десятилетие, начинающим администраторам все так же трудно разобраться в сложной иерархической организации DNS.
.
Интеграция Active Directory и DNS
Чтобы понять, как DNS сочетается с AD, подготовим типовую структуру AD для средних и крупных компаний. Построим один лес с двумя доменами (рисунок 1). Первый домен часто именуется пустым корневым (empty root) или просто корневым доменом. Пустой корневой домен находится на верхнем уровне иерархии AD и, как видно из имени, не содержит никаких ресурсов. Благодаря доменам такого типа компании получают более гибкие и лучше разделенные роли безопасности, нежели в единственном лесе/единственном домене. Второй домен расположен ниже пустого корневого и потому является дочерним; он функционирует как основной домен компании, в котором расположены ресурсы (например, группы, учетные записи пользователей и компьютеров).
|
Рисунок 1. Один лес с двумя доменами |
Начнем с запуска утилиты Dcpromo на первом сервере, чтобы создать лес и пустой корневой домен. Зарегистрируйтесь на сервере Server 2008 R2 в качестве администратора. Убедитесь, что серверу назначено подходящее имя, такое как DC1, и задайте IP-адрес, маску подсети и шлюз по умолчанию на сетевом адаптере сервера. Настройки DNS для сетевого адаптера можно оставить пустыми и предоставить Windows ввести локальный адрес.
Запустите утилиту Dcpromo из меню Start и создайте новый лес и домен с именем ADcompany.com. Обратите внимание, что я использовал AD как приставку к имени компании, чтобы разделить внутренние и внешние пространства имен DNS. ADCOMPANY будет именем NETBIOS для домена. Хотя домен предназначен только для внутреннего использования, важно зарегистрировать домен ADcompany.com в Интернете, чтобы исключить случайное перенаправление клиентов на устройство вне зоны контроля компании. Также принято использовать иерархию пространства имен AD.company.com, где AD становится именем NETBIOS для домена. В этом случае, если имя company.com уже зарегистрировано компанией в Интернете, не требуется никаких дополнительных действий.
На экране Additional Domain Controller Options должен быть установлен флажок DNS server. Нажмите кнопку Next, и Dcpromo начнет проверять назначенные параметры. Система выдаст предупреждение о невозможности создать делегирование, так как не найдена полномочная родительская зона. Другими словами, Dcpromo не может найти полномочный сервер DNS (то есть сервер, содержащий основной или вторичный экземпляр данных зоны для домена. com), где можно создать зону делегирования для домена ADcompany.com.
В зоне DNS содержатся все записи ресурсов для одной части пространства имен, такой как ADCOMPANY или COM. Это внутренний корневой домен AD, поэтому запись делегирования в общедоступной зоне COM необязательна, и предупреждение можно игнорировать. Значение делегирования прояснится после создания дочернего домена.
Тестирование с использованием Dcdiag
После завершения работы Dcpromo перезагрузите сервер. Чтобы убедиться, что с новым сервером все в порядке, откройте командную строку и запустите утилиту Dcdiag. Если DNS и другие важные компоненты AD настроены верно, последовательность тестов будет выполнена успешно.
Перед запуском Dcdiag нужно очистить журналы событий System и DFS Replication, чтобы не получать сообщения о сбоях из-за сообщений об ошибках в ходе организации домена. Например, ошибки репликации DFS обычно регистрируются при первом запуске Dcdiag на новом контроллере домена (DC). Однако их появление не обязательно свидетельствует о неполадках DNS, которые часто оказываются причиной отказов репликации. После очистки журналов событий запустите команду
dcdiag/test: dfsrevent
Тест должен завершиться успешно.
Пока не задан источник времени, будут наблюдаться ошибки службы W32tm (служба Windows Time) в ходе проверок Dcdiag для контроллера корневого домена. Сведения о настройке службы Windows Time приведены в статье Microsoft «How to configure an authoritative time server in Windows Server» по адресу support.microsoft.com/kb/816042.
Корневые ссылки
Если AD DNS функционирует, а DC подключен к Интернету, установленный сервер DNS должен преобразовывать имена доменов Интернета, хотя серверы пересылки не настроены и не указан IP-адрес сервера DNS провайдера Интернета в настройках сетевого адаптера DC. Сервер DNS содержит корневые ссылки, указывающие на серверы DNS верхнего уровня в Интернете. Таким образом можно обслуживать запросы относительно имен, которых он не имеет в своем кэше.
Чтобы увидеть корневые ссылки, загруженные из файла cache.dns, откройте оснастку DNS из раздела Administrative Tools в меню Start. В консоли DNS щелкните правой кнопкой мыши на сервере DNS в левой области и выберите пункт Properties. В диалоговом окне свойств сервера перейдите на вкладку Root Hints (экран 1).
|
Экран 1. Просмотр корневых ссылок |
Иногда возникают ситуации (например, если требуется использовать службу OpenDNS для фильтрации веб-контента), в которых вместо корневых ссылок для преобразования имен Интернета применяется сервер пересылки. Проектируя инфраструктуру DNS, помните, что, если на сервере DNS заданы серверы пересылки, они используются для преобразования имен прежде корневых ссылок.
Итеративные и рекурсивные запросы
Запросы, сделанные сервером DNS для преобразования имен с использованием корневых ссылок, — итеративные, то есть принимается лучший ответ (который может быть ссылкой на сервер имен, расположенный на более низких ступенях иерархии и способный определенно разрешить запрос). Иное дело DNS-клиент Windows, который направляет рекурсивные запросы серверу DNS, требуя определенного ответа или ошибки с сообщением, что данный ресурс не существует. Рекурсивные запросы обычно направляются клиентами DNS или серверами пересылки.
Настройка конфигурации дочернего домена
После успешной проверки преобразования внутренних и интернет-имен в корневом домене, можно добавить дочерний домен с именем HR (HR.ADcompany.com), в котором будут находиться все ресурсы. Зарегистрируйтесь на втором компьютере Server 2008 R2 в качестве локального администратора и убедитесь, что ему назначено подходящее имя, например DC2. Назначьте IP-адрес и маску подсети, затем задайте основной сервер DNS для сетевого адаптера сервера, указав IP-адрес контроллера домена в корневом домене. После запуска Dcpromo должны быть обнаружены корневой домен DNS и контроллер домена, поэтому необходимо настроить сервер DNS, способный ответить на эти запросы.
Прежде чем начать, выполните команду
dcdiag/test: dcpromo/dnsdomain: HR . ADcompany.com/ChildDomain
чтобы убедиться в правильности настроек, необходимых для назначения сервера контроллером домена, указанного с использованием ключа /dnsdomain.
Запустите Dcpromo из меню Start, на этот раз чтобы создать новый домен в существующем лесу. На экране Network Credentials введите лес домена (ADcompany.com) и учетную запись, имеющую членство в группе Enterprise Administrators в корневом домене (экран 2). В диалоговом окне Name the New Domain введите полное имя FQDN корневого домена (ADcompany.com) и однокомпонентное имя для нового дочернего домена (HR), как показано на экране 3. В диалоговом окне Additional Domain Controller Options выберите DNS server. На остальных этапах принимайте параметры по умолчанию.
|
Экран 2. Создание нового домена в существующем лесу |
|
Экран 3. Назначение имени новому домену |
В ответ на приглашение перезагрузите сервер и запустите Dcdiag на контроллере домена HR, чтобы убедиться в правильности функционирования всех компонентов. При запуске Dcdiag соблюдайте рекомендации, приведенные выше.
Откройте командную строку и выполните
ipconfig/all
Обратите внимание, что основной сервер DNS сетевого адаптера сервера настроен на локальный адрес сервера, а IP-адрес сервера DNS корневого домена смещен для использования в качестве дополнительного сервера DNS.
Делегирование и пересылка
Продолжая работать из командной строки, проверьте, можно ли установить связь с контроллером домена в корневом домене, используя однокомпонентное имя контроллера домена (DC1) или полное имя (DC1.ADcompany.com). При наличии подключения к Интернету должна существовать связь с именем домена в Интернете из дочернего DC домена. С контроллера корневого домена проверьте связь с DC в дочернем домене. Сервер DNS в дочернем домене направляет запросы к ресурсам ADcompany.com на сервер пересылки, автоматически настраиваемый в ходе выполнения Dcpromo. Увидеть конфигурацию можно, открыв консоль сервера DNS на контроллере дочернего домена из раздела Administrative Tools меню Start. В консоли DNS щелкните правой кнопкой мыши сервер в левой панели и выберите пункт Properties. В диалоговом окне свойств перейдите на вкладку Forwarders; видно, что сервер настроен на пересылку всех запросов, которые не удается обработать, на сервер DNS корневого домена. Пересылаются как внутренние, так и интернет-запросы; в этом отличие от сервера условной пересылки, настроенного на пересылку запросов, которые не удается обработать локально, только для определенного пространства имен.
В противоположность этому, на сервере DNS корневого домена находится запись делегирования (иногда именуемая зоной делегирования) для домена HR. Запись также настраивается как часть процесса Dcpromo для контроллера дочернего домена и позволяет контроллеру корневого домена обнаружить ресурсы в дочернем домене. Откройте консоль DNS на контроллере корневого домена; в левой панели разверните узлы DNS Server, Forward Lookup Zones, ADCompany.com. Щелкните зону делегирования HR в нижней части дерева. В правой панели находится запись типа A узла для сервера DNS дочернего домена. Делегирование и пересылка — стандартные механизмы Windows Server для преобразования в верхних и нижних областях непрерывного пространства имен DNS, как показано на рисунке 2.
|
Рисунок 2. Делегирование и пересылка |
Регрессирование DNS
Регрессирование DNS — функция DNS-клиента Windows. Это не новшество Server 2008 R2 или Windows 7, однако таким образом удается повысить уровень безопасности. С контроллера дочернего домена можно проверить связь с ресурсами в корневом домене, не указывая имя FQDN (то есть связаться с DC1, не вводя DC1.ADcompany.com). То же относится к DC корневого домена; можно успешно проверить связь с DC2 без имени FQDN.
По умолчанию в ходе регрессирования предпринимается попытка преобразовать однокомпонентное имя, добавляя домены из основного суффикса DNS (PDS) клиента. Поэтому компьютер, принадлежащий домену AD.contoso.com, в первую очередь попытается разрешить имя компьютера как DC1.AD.contoso.com, а затем DC1.contoso.com. Попытки разрешить DC1.com не будет, так как уровень регрессирования по умолчанию — 2 (стандартное значение в Windows до появления Server 2008 R2 и Windows 7). В некоторых ситуациях уровень по умолчанию 2 порождает опасения в отношении безопасности, если клиенты DNS пытаются преобразовать полные имена (FQDN) за пределами контроля компании. Например, рассмотрим следующий набор запросов при уровне регрессирования, равном 2: DC1.HR.company.co.us, DC1.company.co.us, DC1.co.us. Последний запрос, DC1.co.us, находится вне области контроля компании, и клиент может случайно установить связь с вредоносным компьютером в Интернете.
В Server 2008 R2 и Windows 7 действие по умолчанию — установить уровень регрессирования равным количеству меток в корневом домене леса (FRD), если PDS завершается корневым доменом леса. В данном случае PDS — HR.ADcompany.com, а корневой домен леса — ADcompany.com, поэтому по умолчанию в Server 2008 R2 и Windows 7 регрессирование включено, а уровень для клиентов DNS установлен равным 2. Компания Microsoft выпустила обновление, чтобы изменить подход к регрессированию DNS в Windows Vista, Windows XP и Windows 2000. Дополнительные сведения об обновлении можно найти в статье Microsoft «Postinstallation behavior on client computers after you install the DNS update» по адресу support.microsoft.com/kb/957579.
Порядок просмотра суффиксов DNS
Если добавить в лес третий домен, finance.ADcompany.com, регрессирование DNS может оказаться недостаточным для преобразования однокомпонентных имен ресурсов в HR.ADcompany.com от клиентов в домене FINANCE. Преобразование однокомпонентного имени совершается из домена FINANCE, если попытаться обратиться к ресурсам в домене HR, когда все устройства находятся в одной физической подсети. Это объясняется тем, что Windows выполняет широковещательную передачу для IP-адреса, если не удается успешно преобразовать имя из локального кэша компьютера или настроенного сервера DNS.
Если использовать Nslookup для тестирования разрешения DNS, выясняется, что без просмотра суффиксов DNS необходимо ввести полное имя ресурса, расположенного в домене HR, поскольку Nslookup, как инструмент для тестирования преобразования имен DNS, использует исключительно DNS. Чтобы протестировать DNS с помощью Nslookup, откройте командную строку из меню Start и введите nslookup.
В ответ на приглашение введите полное или однокомпонентное имя, которое нужно преобразовать, и нажмите клавишу Enter. Nslookup выдаст IP-адрес или сообщит о неудачном завершении поиска.
Если разрешение однокомпонентных имен во всех доменах AD имеет большое значение, то можно настроить порядок просмотра суффиксов DNS на всех устройствах, составив список всех основных суффиксов DNS, которые нужно разрешать (например, finance.ADcompany.com, HR.ADcompany.com и ADcompany.com). Если суффикс DNS настроен для клиента DNS, регрессирование DNS автоматически отключается. Порядок просмотра можно настроить вручную (выберите Change adapter settings в центре управления сетями и общим доступом Windows 7) для каждого сетевого адаптера на вкладке DNS в диалоговом окне Advanced TCP/IP Settings для свойств IPv6 и IPv4. Иначе порядок просмотра можно настроить с использованием списка с разделительными запятыми из параметра DNS Suffix Search List в разделе Computer Configuration, Policies, Administrative Templates, Network, DNS Client in Group Policy (для Windows Server 2003, XP и более поздних версий).
Аналогично, если сформировать новую зону DNS, secure.HR.ADcompany.com, на сервере DNS HR с целью создания отдельной зоны для важных ресурсов сервера, защищенных с использованием расширений безопасности DNS (DNSSEC), то необходимо установить порядок просмотра суффикса DNS, чтобы клиенты DNS могли обнаружить ресурсы в новой зоне по однокомпонентному имени. В этом случае требуется новая зона DNS, так как DNSSEC не поддерживает динамические обновления — возможность клиентов хранить записи для автоматического обновления сервера, что является обычным и желательным режимом зон DNS, в которых хранятся записи узлов для клиентских компьютеров.
Как правило, IP-адреса компьютеров серверов не изменяются, поэтому защищенными зонами можно управлять вручную.
Условная пересылка
Кроссдоменные запросы для двух дочерних доменов, finance.ADcompany.com и HR.ADcompany.com, можно разрешать более эффективно, не отправляя рекурсивные запросы в сервер DNS в корневом домене леса, если настроить условную пересылку на серверах DNS в обоих дочерних доменах. Условная пересылка имеет приоритет перед пересылкой на уровне сервера. Ее эффективность выше благодаря возможности передавать запросы к определенным доменным суффиксам на заранее определенный сервер DNS, как показано на рисунке 3.
|
Рисунок 3. Условная пересылка |
Сервер DNS в HR.ADcompany.com будет содержать сервер пересылки, который отправляет все запросы для finance.ADcompany.com на основной сервер DNS для домена FINANCE и наоборот. Для настройки условной пересылки откройте консоль DNS на контроллере домена в домене HR из раздела Administrative Tools меню Start. В левой панели консоли DNS разверните DNS server, щелкните правой кнопкой мыши Conditional Forwarders и выберите из меню пункт New Conditional Forwarder. В диалоговом окне New Conditional Forwarder введите finance.adcompany.com в поле DNS Domain. В поле IP addresses of the master servers введите IP-адрес или имя сервера DNS в домене FINANCE и нажмите клавишу Enter. Нажмите кнопку OK, затем повторите процесс на сервере DNS в домене FINANCE, но укажите HR.ADcompany.com в поле DNS Domain и IP-адрес сервера DNS в домене HR.
Сложности DNS
В одной статье невозможно всесторонне рассмотреть проблему. Например, существуют два типа зон, дополнительные и зоны-заглушки, с помощью которых можно повысить производительность, а также новая функция Server 2008 R2, такая как DNSSEC. Но понимание основ совместной работы DNS и AD в интегрированном решении поможет более успешно развертывать AD и выполнять диагностику. Главное, в ходе тестирования новой или существующей инфраструктуры AD убедитесь, что каждый домен может обращаться к ресурсам во всех доверенных доменах. Кроме того, организуйте делегирование и условную пересылку для разрешения между пространствами имен. Соблюдение этих основных правил поможет более эффективно использовать DNS в сложной среде AD.
Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами
Инфраструктура DNS требует настроить конфигурацию клиентов и серверов. В типичной сети настройка DNS-клиентов осуществляется через параметры, унаследованные из DHCP или членства в домене Active Directory. Однако для компьютеров со статической конфигурацией IP, а также машин, не входящих в окружение Active Directory, параметры DNS-клиента нужно задавать вручную. На этом занятии мы рассмотрим параметры DNS, которые позволяют компьютеру успешно разрешать имена DNS, а также разрешать имя компьютера другими машинами.
Указание DNS-серверов
Самым важным параметром конфигурации DNS-клиента является адрес DNS— сервера. Когда клиент выполняет запрос DNS, он вначале пересылает этот запрос по адресу предпочтительного DNS-сервера клиента. Если предпочтительный DNS-сервер недоступен, DNS-клиент обращается к альтернативному DNS-серверу, если таковой указан. Отметим, что клиент не обращается к альтернативному DNS-серверу в случае доступности предпочтительного сервера лишь потому, что последний не может разрешить запрос.
Параметры DNS-сервера можно отконфигурировать с помощью списка, состоящего из множества приоритетных адресов DNS-серверов по своему усмотрению, использовать DHCP для назначения списка либо указать эти адреса вручную. При использовании DHCP клиентов можно отконфигурировать с помощью опции 006 DNS-сервер (006 DNS Server), а затем настроить автоматическое получение клиентом адреса DNS-сервера в диалоговом окне Свойства: Протокол версии 4 (TCP/IPv4) (Internet Protocol 4 (TCP/IPv4) Properties). Этот параметр назначается по умолчанию.
Чтобы настроить список DNS-серверов вручную, нужно использовать диалоговое окно свойств протокола TCP/IPv4 и назначить в нем один или два DNS-сервера (предпочтительный и альтернативный).
Чтобы (сконфигурировать более длинный список, щелкните кнопку Дополнительно (Advancved) и перейдите па вкладку DNS. С помощью кнопки Добавить (Add) добавьте серверы в список приоритетных DNS-серверов.
Указание имени компьютера и DNS-суффиксов
При установке Windows Server 2008 на компьютере или сервере имя компьютера генерируется автоматически, если оно не указано в файле ответов. После установки это имя можно изменить в диалоговом окне Свойства системы (System Properties). Окно свойств системы можно открыть из апплета Система (System) в панели управления или с помощью команды sysdm.cpl. В DNS это имя компьютера называется именем узла. Имя узла компьютера можно определить с помощью команды hostname в командной строке.
Но клиент также может использовать возможности служб разрешения имен DNS, если ему назначить не только имя узла, но и основной DNS-суффикс. Имя узла с DNS-суффиксом составляет так называемое полное имя компьютера. Компьютер ClientA с основным DNS-суффиксом microsoft.com получает полное имя ClientA.microsoft.com. Обычно основной DNS-суффикс соответствует имени основной зоны (с правом чтения/записи), управляемой локально назначенным предпочтительным DNS-сервером. Например, на клиенте ClientA.microsoft.com обычно конфигурируется адрес DNS-сервера, управляющего зоной microsoft.com.
Основной DNS-суффикс выполняет две функции. Он позволяет клиенту автоматически регистрировать собственные записи узла в зоне DNS, имена которой соответствуют имени основного DNS-суффикса. Эта запись узла позволяет другим компьютерам разрешать имя локального DNS-клиента. Кроме того, DNS-клиент автоматически добавляет основной DNS-суффикс в запросы DNS, которые имеют суффиксы.
В процессе присоединения компьютера к домену Active Directory имя домена автоматически конфигурируется с основным DNS-суффиксом компьютера. Чтобы настроить основной DNS-суффикс вне домена Active Directory, на вкладке Имя компьютера (Computer Name) диалогового окна Свойства системы (System Properties) щелкните кнопку Изменить (Change) и в открывшемся диалоговом окис Изменение имени компьютера или домена (Computer Name / Domain Changes) щелкните кнопку Дополнительно (More). Откроется диалоговое окно DNS-суффикс и NetBIOS-имя компьютера (DNS Suffix And NetBIOS Computer Name).
Настройка DNS-суффикса подключения
Помимо основного DNS-суффикса компьютеру можно назначить суффикс подключения; делается это с DHCP-сервера или вручную. Этот тип суффикса связан лишь с отдельным сетевым подключением. С DHCP-сервера суффикс подключения назначается с помощью опции 015 Доменное имя (015 DNS Domain Name). Суффикс подключения можно назначить вручную для любого сетевого подключения па вкладке DNS диалогового окна Дополнительные параметры TCP/IP (Advanced TCP/IP Settings).
Суффикс подключения удобно использовать на компьютере с двумя сетевыми адаптерами для распознавания по имени двух маршрутов к этому компьютеру. На рисунке ниже компьютер УзелА подключен к двум подсетям через два отдельных адаптера. Первый адаптер с адресом 10.1.1.11 подключен к подсети 1 через медленное (10 Мбит/с) подключение Ethernet, которому назначен DNS- суффикс public.example.microsoft.com. Второй адаптер с адресом 10.2.2.22 подключен к подсети 2 через подключение Fast Ethernet (100 Мбит/с). Этому быстрому подключению назначен DNS-суффикс backup.example.microsoft.com.
Настройка поискового списка суффиксов
Для DNS-клиентов можно отконфигурировать поисковый список доменных DNS-суффиксов, чтобы расширить или изменить их поисковые способности DNS. Добавив суффиксы в список, можно выполнить поиск коротких неквалифицированных имен в нескольких указанных DNS-доменах. В случае ошибки запроса DNS служба DNS-клиент (DNS Client) может использовать этот список для прикрепления других суффиксов к исходному имени и многократной отправки запросов на DNS-сервер с целью поиска альтернативных имен FQDN.
Поиск DNS-суффиксов по умолчанию
По умолчанию служба DNS-клиент сначала прикрепляет к неквалифицированному имени локального компьютера основной DNS-суффикс. Если этот запрос не разрешает имя, служба DNS-клиент добавляет все суффиксы подключения, назначенные этому сетевому адаптеру. Если эти запросы также не разрешают имя, служба DNS-клиент добавляет родительский суффикс основного DNS-суффикса.
DNS-клиент добавляет родительский суффикс основного DNS-суффикса. Предположим, что полное имя многосетевого компьютера — computer1. domain1.microsoft.com. Сетевым адаптерам на компьютере Computer1 назначены суффиксы подключения subnet1.domain1.microsoft.com и subnet2.domain1.microsoft.com. Если на этом компьютере ввести в текстовое поле Адрес (Address) Internet Explorer имя computer2 и нажать клавишу Enter, локальная служба DNS-клиент попытается разрешить имя Computer2, запросив имя computer2. domain1.microsoft.com. Если этот запрос не разрешит имя, служба DNS-клиент запросит имена computer2.subnet1.domain1.microsoft.com и computer2.subnet2.domain1.microsoft.com. Если и этот запрос не разрешит имя, служба DNS-клиент запросит имя computer2.microsoft.com.
Настраиваемые поисковые списки DNS-суффиксов
Поиск суффиксов можно настроить, создав список DNS-суффиксов в окне Дополнительные параметры TCP/IP (Advanced TCP/IP Settings).
Опция Дописывать следующие DNS-суффиксы (Append These DNS Suffixes) позволяет указать список DNS-суффиксов, которые будут добавляться к неквалифицированным именам. DNS-суффиксы поискового списка служба DNS- клиент добавляет в указанном порядке, не пытаясь использовать другие доменные имена. Например, если отконфигурировать суффиксы в соответствии с поисковым списком и подтвердить запрос неквалифицированного имени из одной метки coffee, служба DNS-клиент вначале запросит имя coffee.wikipedia.org, а затем имя coffee.eu.wikipedia.org.
Поисковый список DNS-суффиксов также можно отконфигурировать в групповой политике. Соответствующий параметр объекта групповой политики Порядок просмотра DNS-суффиксов (DNS Suffix Search List) находится в папке Конфигурация компьютераАдминистративные шаблоныСетьDNS-клиент (Computer ConfigurationAdministrative ToolsNetworkDNS Client).
Настройка параметров динамического обновления
С настроенным динамическим обновлением DNS-серверы Windows Server 2008 могут принимать динамическую регистрацию и обновления записей А (узел), АААА (IPv6-узел) и PTR (указатель). Саму регистрацию и обновления нужно выполнять с помощью DNS-клиента или DHCP-сервера (от лица DNS-клиеита).
ПРИМЕЧАНИЕ: Записи узлов и указателей
Запись узла в зоне прямого поиска возвращает адрес компьютера при запрашивании его по имени. Это самая важная запись ресурса. Запись указателя выполняет противоположное: она есть только в зонах обратного поиска, и возвращает имя компьютера при запрашивании его IP-адреса. Более подробные сведения о типах зон и записях ресурсов можно найти в главе 3.
Динамическое обновление отдельных клиентов выполняется только в том случае, если они отконфигурированы с помощью основного DNS-суффикса или суффикса подключения, соответствующего имени зоны, управляемой предпочтительным DNS-сервером. Например, для динамического обновления компьютера Client1 в зоне google.ru именем FQDN этого компьютера должно быть client1.google.ru, и клиент должен указать в качестве предпочтительного DNS-сервера IP-адрес DNS-сервера, управляющего основной зоной google.ru.
Обновление записей узлов по умолчанию
Клиент с включенным параметром Зарегистрировать адреса этого подключения в DNS (Register This Connection’s Addresses In DNS) пытается регистрировать обе записи — А и АААА — с помощью предпочтительного DNS-сервера. Для успешной регистрации записи узла требуется выполнение определенных условий. Во-первых, локальной машине нужно назначить основной DNS-суффикс (вручную или через членство в домене Active Directory). Во-вторых, предпочтительный DNS-сервер, указанный для клиента, должен управлять основной зоной, соответствующей имени основного DNS-суффикса клиента. Наконец, основную зону, управляемую предпочтительным DNS-сервером, нужно настроить для разрешения типа динамических обновлений клиента: безопасное обновление (только с членов домена) или оба типа, безопасного и небезопасного обновления (как с членов домена, так и с компьютеров, не присоединенных к домену).
ПРИМЕЧАНИЕ: Автоматическая адресация и автоматическое обновление DNS
DNS-клиенты никогда не пытаются регистрировать IPv4-адреса APIPA или локальные APv6-адреса каналов с помощью DNS-сервера.
Компьютер с включенным параметром Использовать DNS-суффикс подключения при регистрации в DNS (Use This Connection‘s DNS Suffix In DNS Registration) пытается регистрировать записи А и АААА для всех DNS-суффиксов, назначенных сетевому подключению. Отметим, что DNS-суффикс подключения не требуется вводить в текстовое поле DNS-суффикс подключения (DNS Suffix For This Connection). Этот суффикс может наследоваться от DHCP-сервера (в частности, с помощью опции 015 Доменное имя (015 Domain Name)). Поэтому если включить этот параметр, DHCP-клиент, назначающий доменное имя DNS с DHCP-сервера, регистрирует записи А и АААА с помощью предпочтительного DNS-сервера. Для успешного выполнения регистрации доменное имя DNS, унаследованное от DHCP-сервера, должно соответствовать имени основной зоны, управляемой предпочтительным DNS-сервером, а основная зона, управляемая предпочтительным DNS-сервером, должна разрешать тип динамических обновлений, которые может выполнять клиент. Кроме того, если клиенту уже назначен основной DNS-суффикс, соответствующий DNS-суффиксу подключения, то при включении этого параметра дополнительные записи узлов не будут регистрироваться.
Чтобы выполнять регистрацию всех записей узлов в DNS, в командную строку введите с привилегиями администратора команду:
Ipconfig/registerdns
Обновление записей указателей
Для клиентов со статическими адресами обновление записей PTR выполняется так же, как и обновление записей узлов (А и АААА). Если включить параметр Зарегистрировать адреса этого подключения в DNS (Register This Connection‘s Addresses In DNS), DNS-клиенты со статическими адресами всегда будут регистрировать и обновлять свои записи указателей на DNS-сервере. Можно зарегистрировать на DNS-сервера PTR— записи клиента со статическим адресом, запустив в командной строке с административными привилегиями на компьютере клиента команду:
Ipconfig/registerdns
Для успешной регистрации требуется выполнение определенных условий. Во-первых, DNS-клиенту нужно назначить соответствующий основной DNS-суффикс. Во-вторых, предпочтительный DNS-сервер клиента должен управлять соответственно настроенными зонами прямого и обратного поиска.
Обновление PTR-записей DHCP-клиентов отличается от обновления записей клиентов со статическими адресами, а обновление PTR-записей DHCP— клиентов в рабочей группе отличается от обновления в среде Active Directory. Далее описано обновление PTR-записей DHCP-клиентов в этих двух средах.
В среде рабочей группы DHCP-клиенты имеют собственные PTR-записи, обновляемые DHCP-сервером. Обновление можно выполнять с помощью команды Ipconfig/renew. Для успешной регистрации требуется соблюдение определенных условий. Во-первых, DNS-клиенту и DNS-серверу нужно назначить этот DNS-сервер как предпочтительный. Во-вторых, на компьютере DNS-клиента нужно включить параметр Зарегистрировать адреса этого подключения в DNS (Register This Connection‘s Addresses In DNS). В-третьих, DNS-клиенту должен быть назначен соответствующий DNS-суффикс (вручную в качестве основного DNS-суффикса или автоматически с DHCP-сервера). Наконец, на DNS-сервере нужно соответствующим образом отконфигурировать зоны прямого и обратного поиска.
В среде Active Directory клиенты DHCP обновляют свои PTR-записи. Для запуска обновления можно использовать команды Ipconfig/registerdns или Ipconfig/renew. Для успешного обновления нужно включить параметр Использовать DNS-суффикс подключения при регистрации в DNS (Use This Connection’s DNS Suffix In DNS Registration). Чтобы включить этот параметр, нужно вначале включить параметр Зарегистрировать адреса этого подключения в DNS (Register This Connection‘s Addresses In DNS). Наконец, для успешного обновления PTR-записи в среде доменных служб Active Directory предпочтительный DNS-сервер клиента должен управлять соответственно отконфигурированными зонами прямого и обратного поиска.
ПРИМЕЧАНИЕ: Регистрация имен подключений с помощью групповой политики
Чтобы компьютеры в сети регистрировали имена DNS подключений, можно использовать групповую политику. В объекте групповой политики откройте папку Конфигурация компьютераАдминистративные шаблоныСетьDNS-клиент (Computer ConfigurationAdministrative ToolsNetworkDNS Client) и включите параметр политики Регистрировать DNS-записи с DNS-суффиксом подключения (Register DNS Records With Connection—specific DNS Suffix).
Просмотр и очистка кэша DNS-клиента
Кэш DNS-клиента (или кэш распознавателя DNS) поддерживается всеми DNS-клиентами. DNS-клиенты проверяют свой кэш распознавателя перед запросом DNS-сервера. При получении DNS-клиентом ответа на запрос от DNS-сервера в кэш распознавателя добавляются новые записи.
Для просмотра кэша DNS-клиента в командную строку введите команду ipconfig/displaydns. Будут показаны все записи, загруженные из локального файла Hosts, а также все недавно полученные записи запросов имен, выполненных системой.
Для очистки кэша DNS-клиента в командную строку можно ввести команду ipconfig flushdns. В качестве альтернативы можно перезагрузить службу DNS-клиент (DNS Client), используя консоль Службы (Services) в опциях Администрирование (Administrative Tools) меню Пуск (Start).