Служба LLMNR (Link-Local Multicast Name Resolution) позволяет организовать одноранговое разрешение имен в пределах одной подсети для IPv4, IPv6 или обоих видов адресов сразу без обращения к серверам, на что не способны ни DNS, ни WINS. WINS предоставляет как клиент-серверную, так и одноранговую службу разрешения имен, но не поддерживает адреса IPv6. DNS, с другой стороны, поддерживает оба тина адресов, но требует Наличия серверов.
Разрешение имен LLMNR, поддерживаемое как в Windows Vista, так и в Windows Server 2008, работает для адресов IPv6 и IPv4 в тех случаях, когда другие службы разрешения имен недоступны, например, в домашних сетях, в небольших предприятиях, во временных сетях или 15 корпоративных сетях, где по каким-то причинам недоступны DNS-службы.
LLMNR призвана дополнить DNS, обеспечивая разрешение имен в случаях, когда обычное DNS-разрешеиие невозможно. Если у вас нет необходимости в NetBIOS, LLMNR может полностью заменить WINS. Полностью заменить DNS не получится, поскольку LLMNR работает только в локальной подсети. Поскольку трафик LLMNR не проходит через маршрутизаторы, вы не рискуете случайно заполнить им сеть.
Как и WINS, LLMNR позволяет преобразовать имя хоста, например, COMPUTLR84, в IP-адрес. По умолчанию LLMNR включена на всех компьютерах под управлением Windows Vista и Windows Server 2008. Эти компьютеры прибегают к LLMNR, если попытки узнать имя хоста через DNS окончились неудачей. В результате, разрешение имен в Widows Vista и в Windows Server 2008 работает следующим образом:
1. Хост посылает запрос на первичный DNS-сервер. Если он не получает ответа или получает сообщение об ошибке, он по очереди посылает запросы на все вторичные DNS-серверы. Если и это не помогло, разрешение имени передается LLMNR.
2. Хост посылает многоадресный UDP-запрос, запрашивая IP-адрес для нужного имени компьютера. Этот запрос идет только по локальной подсети.
3. Каждый компьютер локальной подсети, поддерживающий LLMNR и сконфигурированный для ответа на поступающие запросы, сравнивает имя со своим хост-именем. Если они не совпадают, компьютер отбрасывает запрос. Если имена совпадают, компьютер пересылает исходному хосту одноадресное сообщение с ІР-адресом.
Вы также можете использовать LLMNR для обратного разрешения. При этом компьютер посылает одноадресный запрос но конкретному ІР-адресу, запрашивая имя хоста. Компьютер с включенной LLMNR, получив запрос, посылает одноадресный ответ, содержащий имя хоста.
Компьютеры с включенной LLMNR должны проверять уникальность своих имен в подсети. В большинстве случаев это происходит при запуске, восстановлении из спящего режима или при смене параметров сетевого интерфейса. Если компьютер еще не проверил уникальность своего имени, он должен указывать это в ответе на запрос.
Широковещательные протоколы NetBIOS over TCP/IP, LLMNR и mDNS (Multicast DNS) используются для разрешения имен в Windows сетях, в которых отсутствует (недоступен) DNS сервер (обычно это домашние или небольшие офисные/SOHO сети). В корпоративных сетях с DNS серверами, эти протоколы обычно не нужны. Более того, эти широковещательные протоколы легко могут использоваться злоумышленниками для реализации спуфинг, relay и MITM атак, позволяющих перехватить учетные данных пользователей в локальной подсети (в т.ч. можно получить хэши NTLM). Разберемся, как отключить протоколы LLMNR, NetBIOS и mDNS в доменной сети Windows вручную и через GPO.
Содержание:
- Широковещательные протоколы LLMNR, NetBIOS и mDNS в Windows сетях
- Отключение протокола LLMNR с помощью GPO
- Отключение протокола NetBIOS over TCP/IP в Windows
- Как отключить NetBIOS через GPO?
- Отключаем mDNS в Windows
Широковещательные протоколы LLMNR, NetBIOS и mDNS в Windows сетях
DNS является предпочтительным методом разрешения имен в Windows сетях. Если в сети отсутствуют DNS сервера, используются альтернативные разрешающие протоколы в следующем порядке:
- MulticastDNS (mDNS)
- Link-Local Multicast Name Resolution (LLMNR)
- NetBIOS (NBNS)
Протокол LLMNR (механизм широковещательного разрешения имен) присутствует во всех версиях Windows, начиная с Vista и позволяет IPv6 и IPv4 клиентам разрешать имена соседних компьютеров без использования DNS сервера за счет широковещательных запросов в локальном сегменте сети L2. Этот протокол также автоматически используется при недоступности DNS (в рабочих группах Windows этот протокол используется для сетевого обнаружения/Network Discovery). Для передачи данных используется порт UDP/5355.
Протокол NetBIOS over TCP/IP или NBT-NS (UDP/137,138;TCP/139) – это широковещательный протокол, предшественник LLMNR, используется в локальной сети для публикации и поиска ресурсов. Поддержка NetBIOS over TCP/IP в Windows по умолчанию включена для всех интерфейсов.
В Windows можно вывести статистику протокола NetBIOS и текущих подключений TCP/IP по NBT с помощью команды nbtstat. Чтобы по IP адресу получить имя компьютера, выполните:
nbtstat -A 192.168.31.90
Утилита через NetBIOS обнаружила в локальной сети компьютер и вернула его имя. Можно получить из кэша NetBIOS все записи о соседних компьютерах в локальных сети:
nbtstat -c
В последних билдах Windows 11, NetBIOS будет использоваться только тогда, когдане получен ответ через mDNS или LLMNR.
Сетевой протокол Multicast DNS (mDNS) доступен начиная с версии Windows 10 1703 ( в Windows Server с версии 2019). Позволяет разрешать имена хостов в IP-адреса в небольших локальных сетях без использования центрального DNS-сервера. Уникальность имен в пределах локальной сети обеспечивается присваиванием суффикса
.local
. Предполагалось, что mDNS должен полностью заменить устаревшие протоколы NetBIOS и LLMNR. Для разрешения имен используется многоадресная рассылка UDP пакетов на порт 5353. mDNS также широко используется для автоматического обнаружения сетевых принтеров и других служб в локальной сети.
Протоколы NetBIOS, LLMNR и mDNS позволяют компьютерам в рабочей группе найти друг друга по именам при недоступности DNS сервера. В доменных сетях эти протоколы можно отключить.
Совет. Перед отключением протоколов NetBIOS, LLMNR и mDNS на всех компьютерах, проведите тестирование. Как правило, с отключением LLMNR обычно проблем нет, то отключение NetBIOS может парализовать работу устаревших систем.
Отключение протокола LLMNR с помощью GPO
В доменной среде широковещательные запросы LLMNR на компьютерах и серверах домена можно отключить с помощью групповой политики. Для этого:
- В консоли
GPMC.msc
создайте новую или отредактируйте имеющуюся политику GPO, которую нужно применить ко всем рабочим станциям и серверам; - Перейдите в раздел Computer Configuration -> Administrative Templates -> Network -> DNS Client;
- Включите политики Turn off multicast name resolution и Turn off smart multi-homed name resolution, изменив их значения на Enabled
- Дождитесь обновления параметров GPO на клиентах или обновите их вручную командой
gpupdate /force
.
Можно отключить LLMNR в Windows, создав эти параметры в реестре с помощью PowerShell:
New-Item "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT" -Name DNSClient -Force
New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMultiCast -Value 0 -PropertyType DWORD -Force
New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name DisableSmartNameResolution -Value 1 -PropertyType DWORD -Force
Отключение протокола NetBIOS over TCP/IP в Windows
Примечание.Протокол NetBIOS может использовать старыми версиями Windows и некоторыми не-Windows системами, поэтому отключение нужно сначала протестировать.
Отключить NetBIOS можно в настройках сетевого адаптера:
- Откройте свойства сетевого подключения в панели
ncpa.cpl - Выберите протокол TCP/IPv4 и откройте его свойства;
- Нажмите кнопку Advanced, затем перейдите на вкладку WINS и выберите опцию Disable NetBIOS over TCP (Отключить NetBIOS через TCP/IP);
- Сохраните изменения.
Если у вас на компьютере несколько сетевых интерфейсов (или отдельных VLAN), нужно будет отключить NetBIOS в свойствах каждого их них.
Проверьте статус NetBIOS over TCP/IP для сетевых адаптеров из командной строки:
ipconfig /all |find "NetBIOS"
NetBIOS over Tcpip. . . . . . . . : Disabled
Можно отключить поддержку NetBIOS для конкретного сетевого адаптера через реестр. Для каждого сетевого адаптера компьютера есть отдельная ветка с его TCPIP_GUID внутри HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces.
Чтобы отключить NetBIOS для конкретного сетевого адаптера, нужно открыть его ветку и изменить значение параметра NetbiosOptions на 2 (по умолчанию значение – 0).
На клиентах домена, получающих IP адреса с DHCP сервера на Windows Server, вы можете отключить NetBIOS через отдельную DHCP опцию.
- Для этого откройте консоль
dhcpmgmt.msc
и выберите настройки зоны Scope Option (или сервера – Server Options); - Перейдите на вкладку Advanced, в выпадающем списке Vendor class выберите Microsoft Windows 2000 Options;
- Включите опцию 001 Microsoft Disable Netbios Option и измените ее значение на 0x2.
Как отключить NetBIOS через GPO?
В редакторе групповых политик или новых административных ADMX шаблонов GPO для Windows нет отдельного параметра, позволяющего отключить протокол NETBIOS over TCP/IP на компьютере. Чтобы отключить NETBIOS для всех адаптеров компьютера воспользуйтесь таким логон скриптом PowerShell.
$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}
Можно использовать более простой код с WMI запросом:
Get-WmiObject -Class Win32_NetworkAdapterConfiguration | % {$_.SetTcpipNetbios(2)}
Сохраните этот код в файл disableNetbios.ps1, скопируйте его в каталог вашей GPO и запускайте на клиентах через Computer Configuration -> Policies -> Windows Settings -> Scripts -> Startup -> PowerShell Scripts.
Примечание. Для вступления изменений в силу, нужно отключить/включить сетевые адаптеры или перезагрузить компьютер.
Затем откройте командную строку и проверьте, что NetBIOS отключен для ваших сетевых адаптеров (кроме туннельных интерфейсов):
wmic nicconfig get caption,index,TcpipNetbiosOptions
Отключаем mDNS в Windows
Для отключения протокола mDNS в Windows, нужно создать на компьютере параметр EnableMDNS со значением 0 в ветке реестра HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters.
Можно создать этот параметр командой:
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v " EnableMDNS" /t REG_DWORD /d "0" /f
Либо применить параметр реестра через Group Policy Preferences (Computer Configuration > Preferences > Windows Settings > Registry)
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path: SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
- Value name: EnableMDNS
- Value type: DWORD
- Value data: 0
Также в GPO можно создать правило Windows Defender Firewall, которое будет блокировать входящий трафик mDNS на клиентах. Можно отключить правило mDNS (UDP-In) только для доменного профиля, чтобы ноутбуки пользователей при работе за пределами домена (офиса) могли обнаруживать в сети соседние устройства через mDNS.
При отключении mDNS у пользователей могут возникнуть проблемы с подключением к беспроводным дисплеям, проекторам через Miracast, а также некоторым принтерам.
Чтобы проверить, что на компьютере отключены NetBIOS, LLMNR и mDNS, выполните команды:
netstat -nao | FIND /i ":137 "
netstat -nao | FIND /i ":5353 "
netstat -nao | FIND /i ":5355 "
Если эти протоколы разрешения имен отключены, команды не должны вернуть открытых портов.
Дополнительно в целях безопасности на компьютерах в корпоративной сети рекомендуется корректно настроить или совсем отключить протокол автонастройки прокси WPAD.
Разрешение имен в сетях Windows Server 2008
При подключении к компьютеру обычно указывается такое имя, как www.microsoft.com или FileSrvB. Однако такие компьютерные имена используются лишь для удобства пользователей. Для подключения к удаленному компьютеру имя должно быть преобразовано в IP-адрес, по которому будет выполняться маршрутизация пакетов. В компьютерной терминологии DNS, или разрешение имени, компьютера означает его преобразование в адрес, а сам процесс такого преобразования называется разрешением имен (DNS).
Разрешение имен является одним из самых важных компонентов сетевой инфраструктуры. Системный администратор Windows должен понимать принцип разрешения имен для настройки и устранения неполадок этого компонента.
Методы разрешения имен в Windows
Сети Windows Server 2008 включают не меньше трех систем разрешения имен: DNS, LLMNR (Link Local Multicast Name Resolution) и NetBIOS. Самой важной является DNS, поскольку этот метод разрешения имен используется для поддержки служб доменов Active Directory (Active Directory Domain Services) и разрешения всех имен Интернета. Таким образом, DNS — наиболее предпочтительный метод разрешения имен в Windows, который по возможности используется во всех ситуациях.
Тем не менее, самой системы DNS недостаточно для разрешения имен во всех сетях Windows. Инфраструктура DNS требует настройки сетевой конфигурации на серверах и клиентах. Такой инфраструктуры DNS нет в небольших и неофициальных сетях. Поэтому, к примеру, DNS нельзя использовать для разрешения имен компьютеров в рабочей группе, на которых система Windows Server 2008 установлена с параметрами по умолчанию. В таких рабочих группах используются другие службы разрешения имен — LLMNR и NetBIOS. В следующем подразделе описаны резервные механизмы разрешения имен.
Link Local Multicast Name Resolution
Метод разрешения имен Link Local Multicast Name Resolution (LLMNR) используется функцией Сетевое обнаружение (Network Discovery), которую можно включить в Центре управления сетями и общим доступом (Network And Sharing Center), представленном на рисунке ниже. Протокол LLMNR применяется только в системах Windows Vista и Windows Server 2008.
Метод LLMNR использует многоадресное вещание для разрешения IPv6- адресов компьютеров лишь в локальной подсети. Протокол LLMNR является более предпочтительным методом разрешения имен, чем NetBIOS. Поэтому LLMNR используется для отдельной подсети без инфраструктуры DNS, содержащей лишь компьютеры Windows Vista и Windows Server 2008, на которых включен протокол IPv6 и Сетевое обнаружение (Network Discovery).
Предположим, на вашем компьютере ClientA установлена система Windows Vista, включен протокол IPv6 и Сетевое обнаружение (Network Discovery). Если вы захотите подключиться к компьютеру ClientB, указав UNC-путь (Universal Naming Convention) в виде \\ClientB в сети без DNS, ваш компьютер для разрешения имени ClientB сначала использует LLMNR.
Компьютер ClientA использует для разрешения этого имени метод LLMNR, проверив сначала в кэше LLMNR локального компьютера ранее разрешенные имена. Если соответствующая запись не найдена, ClientA через IPv6 отправит LLMNR-запрос имени (Name Query Request) на широковещательный (Multicast) адрес FF02::1:3. Все IPv6-yзлы в сети с включенным сетевым обнаружением прослушивают трафик, пересылаемый на этот широковещательный адрес. Если ClientB с включенным сетевым обнаружением расположен в той же подсети, компьютер отреагирует на запрос и перешлет на компьютер ClientA свой IPv6- адрес. После этого ClientA сможет установить соединение с машиной ClientB. Описываемый процесс продемонстрирован ниже.
ПРИМЕЧАНИЕ: Протокол LLMNR в IPv4
Протокол LLMNR также отправляет запросы разрешения имен в IPv4 (в частности, по адресу 224.0.0.252), однако во время написания этой книги клиенты Windows Server 2008 и Windows Vista по умолчанию не отвечали на эти запросы.
В качестве механизма разрешения имен LLMNR обеспечивает несколько важных преимуществ. Во-первых, для разрешения имен компьютеров в локальной подсети не требуется конфигурация. Во-вторых, в отличие от NetBIOS метод LLMNR совместим с IPv6. Таким образом, LLMNR является единственным протоколом разрешения имен, который работает без конфигурации в IPv6- сетях Windows. В-третьих, по сравнению с NetBIOS метод LLMNR компактней и, следовательно, имеет меньший фронт атаки.
Однако LLMNR имеет и множество недостатков, в частности этот метод не разрешает имена компьютеров с системами Windows Server 2003, Windows XP и другими предыдущими версиями Windows. Кроме того, LLMNR не позволяет устанавливать соединения с клиентами в lPv4-сети Windows. Более того, для работы LLMNR на всех компьютерах в подсети нужно включить сетевое обнаружение, то есть, даже не требуя конфигурирования, этот протокол не разрешает имена компьютеров по умолчанию. Но самый значительный недостаток LLMNR заключается в том, что этот протокол нельзя использовать для разрешения имен компьютеров за пределами локальной подсети.
ПРИМЕЧАНИЕ: Отключение LLMNR в сети
Протокол LLMNR можно отключить сразу для большого числа компьютеров с помощью групповой политики. В объекте групповой политики (Group Policy Object, GPO) откройте папку Конфигурация компьютера\Административные шаблоны\Сеть\DNS-клиент (Computer Configuration\Administrative Templates\Network\DNS Client) и найдите параметр политики Отключить многоадресное разрешение имен (Turn Off Multicast Name Resolution).
Разрешение имен NetBIOS
Устаревший протокол и система именования NetBIOS или NetBIOS через TCP/IP (NetBT или NBT) используется для обеспечения совместимости со старыми сетевыми службами Windows. Хотя NetBIOS в определенных ситуациях можно отключить, сетевой администратор должен уметь конфигурировать, управлять и устранять неполадки разрешения имен NetBIOS.
Протокол NetBIOS по умолчанию обеспечивает разрешение имен в IPv4- сетях Windows без DNS. Например, в домашней беспроводной сети можно подключаться к другим компьютерам, указывая их имена UNC (\\Comp3), не включая Сетевое обнаружение (Network Discovery), даже если на машине CompЗ установлена операционная система Windows XP. Протокол NetBIOS также позволяет проверить имя CompЗ с помощью команды ping и получить ответ с IPv4-адреса этого компьютера. система Windows всегда будет вначале пытаться разрешить имя с помощью DNS, а в случае недоступности DNS попытается использовать LLMNR и NetBIOS. В данном случае понятно, что для разрешения имени система Windows использует NetBIOS, поскольку в имя компьютера не включен домен DNS (например, mydomain.com) и ответ на запрос пришел с IPv4-адреса. (Ответ с IPv4-адреса означает использование LLMNR).
Методы разрешения имен NetBIOS
Протокол NetBIOS включает три метода разрешения имен: широковещание, WINS и файл Lmhosts.
■ Широковещание NetBIOS
Такой метод разрешения имен NetBIOS заключается в широковещании через IPv4. Для подключений по локальной сети в Windows протокол NetBIOS включен по умолчанию. Таким образом, компьютер, которому требуется разрешить имя, выполняет широковещательный запрос IPv4-адреса собственника имени в локальной сети.
■ WINS-сервер
По сути, WINS-сервер представляет каталог таких имен компьютеров, как Client2 и ServerB, и связанные с ними IP-адреса. При настройке сетевого подключения с адресом WINS-сервера выполняются два действия. Во-первых, вы разрешаете компьютеру выполнять поиск компьютерных имен, которые нельзя разрешить с помощью DNS или LLMNR. Во- вторых, вы регистрируете имя локального компьютера в каталоге WINS- сервера. Главное преимущество WINS состоит в том, что WINS-сервер включает разрешение имен NetBIOS за пределами локальной подсети.
■ Файл Lmhosts
Статический файл локальной базы данных, который хранится в папке %SystemRoot%\System32\Drivers\Etc и сопоставляет конкретные имена NetBIOS адресам IP. Запись имени NetBIOS и связанного IP-адреса в файл Lmhosts позволяет компьютеру разрешать IP-адрес для данного имени NetBIOS в случае сбоя другого метода разрешения имен. Файл Lmhosts требуется создать вручную. Поэтому он обычно используется с целью разрешения имен удаленных клиентов, для которых недоступны другие методы разрешения имен — например, когда в сети нет WINS-сервера, удаленный клиент не зарегистрирован с помощью DNS-сервера или когда клиентский компьютер расположен за пределами диапазона широковещания.
Включение и отключение NetBIOS
По умолчанию протокол NetBIOS включен для каждого подключения по локальной сети IPv4. Чтобы изменить параметры NetBIOS, откройте свойства подключения по локальной сети. Затем откройте свойства протокола Интернета версии 4 (TCP/IPv4) и щелкните кнопку Дополнительно (Advanced), чтобы открыть диалоговое окно Дополнительные параметры TCP/IP (Advanced TCP/ IP Settings). В этом диалоговом окне перейдите на вкладку Служба WINS (WINS).
Подключение по локальной сети по умолчанию разрешает WINS-серверу назначать параметры NetBIOS. Параметры NetBIOS, полученные с DHCP-сервера, не просто включают или отключают NetBIOS: DHCP-сервер может конфигурировать клиента в качестве конкретного типа узла NetBIOS.
Типы узлов NetBIOS
Механизм, посредством которого имена NetBIOS разрешаются в IP-адреса, зависит от типа узла NetBIOS, отконфигурированного для компьютера.
Существует четыре типа узлов.
■ Широковещательный (b-узел)
Этот тип узла использует широковещательные запросы имен NetBIOS для регистрации и разрешения имен. В-узел имеет два недостатка: широковещание затрагивает все узлы в сети, а маршрутизаторы, как правило, блокируют широковещание, так что разрешаться будут лишь имена NetBIOS в локальной сети. Принцип работы этого типа узлов больше других похож на LLMNR.
■ Узел точка—точка (р—узел)
Этот тип узла использует коммуникации точка- и WINS-сервер для разрешения имен. Р-узел не применяет широковещание, а напрямую запрашивает сервер имен.
■ Комбинированный (m-узел)
Данный тип узла вначале использует широковещание (b-узел), а затем, если имя не было разрешено с помощью широковещания, применяет запросы WINS-сервера (р-узел).
■ Смешанный (h-узел)
Этот тип узла вначале использует запросы WINS (р-узел), а затем — широковещание (b-узел), если сервер имен недоступен или имя не зарегистрировано в базе данных WINS. Однако до внедрения широковещания b-узла эти компьютеры также используют файл Lmhosts для поиска сопоставлений имени в IP-адрес. По умолчанию клиенты Windows конфигурируются с комбинированным, или h-узлом. Текущее состояние узла, назначенного компьютеру Windows, можно определить в результатах команды Ipconfig /all, как показано в примере. Отметим, что на этом компьютере назначен смешанный тип узла.
Преимущества и недостатки NetBIOS
Основные преимущества NetBIOS как механизма разрешения имен в том, что вначале протокол NetBIOS по умолчанию разрешает имена соседних компьютеров, не требуя конфигурации, и он включен во все версии Windows. Кроме того, при добавлении WINS-сервера в инфраструктуру разрешения имен NetBIOS можно использовать (аналогично DNS и в отличие от LLMNR) для разрешения имен компьютеров в соседних подсетях. (В частности, эта возможность используется в случае, когда удаленные компьютеры не зарегистрированы в DNS-зоне.) Другие преимущества NetBIOS заключаются в том, что конфигурировать и управлять NetBIOS легче, чем DNS, и в отличие от LLMNR протокол NetBIOS работает в IPv4-узлах.
Главное ограничение NetBIOS состоит в том, что, хотя этот протокол обеспечивает резервный метод разрешения имен компьютеров в пределах диапазона широковещания и небольших сетях, он неэффективен в больших сетях. В NetBIOS каждому компьютеру назначается только одно имя или метка. Если вы используете WINS для разрешения имен NetBIOS в подсетях, имя каждого компьютера должно быть уникальным для всей сети. Еще один недостаток NetBIOS состоит в том, что этот протокол не рекомендуется использовать в тех случаях, когда требуется высокий уровень безопасности. Система NetBIOS разглашает информацию о сетевых службах, которая может быть использована для взлома сети. И, наконец, протокол NetBIOS несовместим с IPv6-сетями.
ПРИМЕЧАНИЕ:
Если вы используете множество WINS-серверов в большой организации, па них нужно отконфигурировать репликацию, чтобы базы данных WINS все время обновлялись. В большинстве случаев на всех WINS-серверах настраивается репликация приема/передачи (push/pull) (особенно при звездообразной конфигурации), чтобы серверы могли эффективно обновлять друг друга.
Разрешение имен DNS
Система DNS позволяет определять по имени компьютеры и другие ресурсы в Интернете. Обеспечивая иерархическую структуру и автоматизированный метод кэширования и разрешения имен узлов, DNS устраняет многие административные и организационные вопросы, связанные с именованием узлов в Интернете и больших частных сетях.
Именное пространство DNS
Система именования DNS основана на иерархической и логической древовидной структуре, которая называется пространством имен DNS. Это пространство имеет уникальный корень с любым количеством субдоменов. Каждый субдомен может располагать доменами нижнего уровня. Например, корень «» (пустая строка) в пространстве имен Интернета располагает множеством доменных имен верхнего уровня, одним из которых является org. Домен org может, например, содержать субдомен wikipedia.org компании Wikipedia, который, в свою очередь, может располагать производственным субдоменом ru.wikipedia.org. Организации также могут создавать частные сети и использовать собственное пространство имен DNS, скрытое для Интернета.
Доменные имена
Каждый узел в доменном дереве DNS можно идентифицировать с помощью полного доменного имени FQDN (Fully Qualified Domain Name). Имя FQDN однозначно указывает расположение домена относительно корня доменного дерева DNS. Например, именем FQDN для сервера wiki в домене wikipedia.org будет wiki.wikipedia.org, представляющее конкатенацию имени узла (wiki) с основным DNS-суффиксом (wikipedia.org) и замыкающей точкой (.). Замыкающая точка является стандартным разделителем между меткой домена верхнего уровня и меткой пустой строки, соответствующей корню доменного дерева DNS. (Обычно в браузерах замыкающая точка отбрасывается, однако служба DNS-клиент (DNS Client) добавляет ее в запросах.)
Корень DNS (самый верхний уровень) доменного пространства Интернета управляется Корпорацией по присвоению имен и номеров в Интернете (Internet Corporation for Assigned Names and Numbers, ICANN). Корпорация ICANN координирует назначение идентификаторов, которые должны быть глобально уникальными, для работы в Интернете, включая доменные имена, значения IP-адресов, а также параметры протоколов и номера портов.
Помимо корня домена DNS корпорация ICANN также управляет доменами верхнего уровня. Существует три типа доменов верхнего уровня.
■ Организационные домены
Эти домены именуются с использованием кода, который указывает основную функцию или род деятельности организаций в DNS-домене. Некоторые такие домены могут использоваться глобально, другие применяются лишь для организаций в США. В качестве известных организационных доменов можно привести домены .com, .net, .edu и .org. Другие организационные домены верхнего уровня включают .aero, .biz, .info, .name и .pro.
■ Географические домены
Эти домены именуются с использованием кодов страны и региона из двух символов согласно стандарту 3166 Международной организации по стандартизации (International Organization for Standardization, ISO), например .uk (Великобритания) или .it (Италия). Эти домены обычно используются организациями вне США, хотя и необязательно.
■ Реверсивные домены
Специальные домены, именуемые in-addr.arpa, используемые для разрешения IP-адресов в имена (в реверсивном поиске).
Под доменами верхнего уровня корпорация ICANN и другие сообщества именования в Интернете (Network Solutions или Nominent в Великобритании) делегируют домены различным организациям, например Microsoft (microsoft.com) или университету (.edu). Эти организации подключаются к Интернету, назначают имена узлам в своих доменах и используют DNS-серверы для управления сопоставлением имен с IP-адресами в своем именном пространстве. Эти организации также могут делегировать субдомены другим пользователям или потребителям. Например, поставщики услуг Интернета (Internet Service Provider, ISP) принимают делегирование от ICANN и могут делегировать субдомены своим потребителям.
Частное доменное пространство имен
Помимо доменов верхнего уровня в Интернете организации также могут иметь частное пространство имен — пространство имен DNS на основе набора приватных корневых серверов, которое не зависит от пространства имен DNS в Интернете. В приватном пространстве имен можно именовать и создавать собственные корневые серверы и любые субдомены. Приватные имена невозможно видеть или разрешать в Интернете. Примером имени приватного домена является имя mycompany.local.
Компоненты DNS
Для работы DNS нужно обеспечить соответствующую конфигурацию DNS-серверов, зон, распознавателей и записей ресурсов.
DNS-серверы
DNS-сервер представляет собой компьютер с программой DNS-сервера (например, служба DNS-сервера в системе Windows Server или Berkeley Internet Name Domain (BIND) в UNIX). DNS-серверы содержат информацию базы данных DNS о некоторой части древовидной структуры доменов DNS и разрешают запросы разрешения имен, поступающие от DNS-клиентов. DNS-серверы могут обеспечивать запрашиваемую информацию, указатель на еще один сервер, который может помочь разрешить запрос, либо сообщают, что информация недоступна или не существует.
Сервер, использующий локально управляемую базу данных (вместо простого кэширования информации с других серверов), является главным сервером домена, отвечающим на запросы об узлах в этом домене. Такие серверы определяют свою часть именного пространства DNS.
Серверы могут быть главными на одном или нескольких уровнях иерархии доменов. В частности, корневые DNS-серверы в Интернете являются главными лишь для доменных имен верхнего уровня, например .com. В результате главные серверы доменов .com имеют приоритет лишь для имен в домене .com, например microsoft.com. Однако внутри пространства имен Microsoft главный сервер или серверы домена microsoft.com также могут быть главными в обоих доменах, например в доменах microsoft.com и widgets.example.microsoft.com.
Смежные домены, например .com, microsoft.com и example.microsoft.com, могут стать отдельными зонами в случае делегирования, посредством которого ответственность за субдомен в именном пространстве DNS назначается отдельной сущности.
Файлы зон содержат данные зон, для которых сервер является главным. Во многих типах реализации DNS-серверов данные зон хранятся в текстовых файлах, однако, DNS-серверы на контроллерах доменов Active Directory могут также хранить информацию зон в Active Directory.
ПРИМЕЧАНИЕ:
Зоны прямого и обратного просмотра
Зоны бывают двух типов: зоны прямого просмотра и зоны обратного просмотра. Основным типом является зона прямого просмотра, имена в которой разрешаются в IP-адреса. В зоне обратного просмотра IP-адрес разрешается в имя. Типы зон подробно описаны в главе 3.
Распознаватели DNS
Распознаватель DNS представляет службу, использующую протокол DNS для запроса информации DNS-серверов. Распознаватели DNS осуществляют коммуникации с удаленными DNS-серверами или программой DNS-сервера на локальном компьютере. В Windows Server 2008 роль распознавателя DNS выполняет служба DNS-клиент (DNS Client). Помимо функций распознавателя DNS служба DNS-клиент обеспечивает дополнительные возможности кэширования сопоставлений DNS.
Записи ресурсов
Записи ресурсов представляют сущности базы данных DNS, которые используются для ответов на запросы клиентов DNS. Каждый DNS-сервер содержит записи ресурсов, которые использует для ответов на запросы своей части пространства имен DNS. Каждая запись ресурсов описана с конкретным типом ресурса, например адрес (А) IPv4-yзлa, адрес (АААА) IPv6-узла, псевдоним (CNAME), указатель (PTR) и почтовый обменщик MX (Mail eXchanger). Эти записи подробно описаны в теме 1 главы 3.
Запрос DNS
Когда DNS-клиенту требуется выполнить поиск имени, используемого приложением, он опрашивает DNS-серверы для разрешения этого имени. Каждое сообщение запроса, отправляемое клиентом, содержит следующие сведения.
■ Имя домена DNS, указанное в формате FQDN. (Служба DNS-клиент добавляет необходимые суффиксы для генерирования имени FQDN, если оно не было указано исходной клиентской программой.)
■ Указанный тип запроса, например запрос записи ресурса по типу или специализированный тип операции запроса.
■ Указанный класс доменного имени DNS. (Для службы DNS-клиент всегда указывается класс Internet [IN].
Так, в запросе можно указать имя FQDN конкретного компьютера (например, host-a.example.microsoft.com.), а в качестве типа запроса указать поиск записи А по этому имени. Запрос DNS как клиент задает серверу, скажем, такой вопрос: «Имеются ли записи А для компьютера hostname.example.microsoft.com?». Получив ответ от сервера, клиент читает полученную запись А и определяет IP-адрес имени компьютера, которое запрашивалось.
Методы разрешения имен DNS
Разрешение запросов DNS выполняется множеством различных способов. В базовом сценарии DNS-клиент связывается с DNS-сервером, который затем использует для ответа на запрос собственную базу данных записей ресурсов. Однако, ссылаясь вначале на свой кэш, DNS-клиент иногда может ответить на запрос, вообще не обращаясь к серверу. Еще один способ разрешения запросов DNS состоит в использовании рекурсии. При этом для разрешения имени FQDN DNS-сервер может запрашивать другие DNS-серверы от лица запрашивающего клиента. Получив ответ на запрос, DNS-сервер пересылает его клиенту. Последний метод разрешения запросов DNS состоит в применении итерации. В этом случае клиент сам пытается связаться с дополнительными DNS- серверами для разрешения имени. При этом клиент использует отдельные дополнительные запросы на основе ответов DNS-серверов. Как правило, клиент выполняет итерацию только в том случае, когда DNS-сервер не отконфигурирован для выполнения рекурсии.
Этапы выполнения запроса DNS
Запрос DNS выполняется в два этапа.
■ С клиентского компьютера запускается запрос имени и передается службе
DNS-клиент (DNS Client) для разрешения.
■ Если запрос нельзя разрешить локально, служба DNS-клиент передает запрос DNS-серверу.
Далее подробно описаны оба этапа выполнения.
Этап 1
.
Локальный распознаватель
По умолчанию DNS-запрос клиента отконфигурирован для выполнения рекурсивных запросов сервера. Если в этом сценарии служба DNS-клиент не может разрешить запрос с помощью локально кэшированной информации (сопоставления имен с адресами, предварительно загружаемые из файла Hosts), клиент отправляет лишь один запрос на DNS-сервер, который затем выполняет его от лица клиента.
Процесс выполнения запроса начинается с использования доменного имени DNS в программе на локальном компьютере. Например, браузер запрашивает имя FQDN для www.microsoft.com. Затем запрос пересылается службе DNS-клиент (кэш распознавателя DNS) для разрешения этого имени с помощью локально кэшированной информации. Если такое имя можно разрешить, отправляется ответ на запрос, и процесс завершается.
Кэш локального распознавателя может включать информацию об имени, полученную из двух возможных источников.
■ При наличии локально отконфигурированного файла Hosts все сопоставления имен узлов в адреса загружаются из файла в кэш при запуске службы DNS- клиент и при каждом обновлении файла Hosts. В Windows Server 2008 записи динамически добавляются в кэш распознавателя, создавая файл Hosts.
■ Записи ресурсов, полученные в ответах на предыдущие запросы DNS, добавляются в кэш и хранятся там некоторое время.
Если запрос не соответствует ни одной записи в кэше, клиент запрашивает DNS-сервер для разрешения имени.
Этап 2. Запрос DNS-сервера
Служба DNS-клиент (DNS Client) использует список поиска серверов, упорядоченный согласно предпочтениям. В этот список включены все предпочтительные и альтернативные DNS-серверы, отконфигурированные для каждого активного сетевого подключения в системе. Клиент вначале запрашивает DNS-сервер, указанный как предпочтительный в диалоговом окне Свойства: Протокол Интернета (TCP/IP) (Internet Protocol (TCP/ IP) Properties). Если предпочтительные DNS-серверы недоступны, используются альтернативные DNS-серверы.
После получения запроса DNS-сервер проверяет возможность приоритетного ответа на запрос на основе информации, содержащейся в локально сконфигурированной зоне на сервере. Если запрашиваемое имя соответствует записи ресурса в данных локальной зоны, сервер отвечает на запрос в приоритетном порядке, используя эту информацию для разрешения запрашиваемого имени.
Если для запрашиваемого имени не нашлось соответствующей записи в информации зоны, сервер проверяет возможность разрешения имени с помощью локально кэшированной информации предыдущих запросов. Если найдена соответствующая запись, сервер отвечает на запрос. Если предпочтительный сервер находит ответ для запрашивающего клиента в своем кэше, выполнение запроса завершается.
Рекурсия
Если запрашиваемое имя не найдено на предпочтительном сервере, в его кэше или данных зоны, дальнейший процесс выполнения запроса зависит от конфигурации DNS-серверов. В конфигурации по умолчанию DNS-сервер выполняет рекурсию для разрешения имени. В терминологии DNS рекурсия представляет собой процесс опроса DNS-сервером других DNS-серверов от лица исходного запрашивающего клиента. В этом процессе исходный DNS-сервер выполняет роль DNS-клиента.
Если рекурсия отключена на DNS-сервере, клиент сам выполняет итеративные запросы в соответствии с корневыми ссылками на DNS-сервере. Итерация представляет собой процесс выполнения DNS-клиентом многократных запросов различных DNS-серверов.
Корневые ссылки
Для правильного выполнения рекурсии DNS-серверу вначале требуется определить точку начала поиска имен в доменном пространстве DNS. Эта информация обеспечивается в виде корневых ссылок — предварительного списка ресурсов, используемого службой DNS с целью локализации главных серверов корня дерева пространства доменных имен DNS.
По умолчанию DNS-серверы в Windows Server 2008 используют предварительно отконфигурированный файл корневых ссылок Cache.dns из папки WINDOWS\System32\Dns. Содержимое этого файла загружается в память сервера при запуске службы и включает указатели на корневые серверы пространства имен DNS.
В Windows Server 2008 файл корневых ссылок уже содержит адреса корневых серверов в пространстве имен DNS Интернета. Поэтому в случае использования службы DNS-сервер в Windows Server 2008 для разрешения DNS-имени Интернета, файл корневых ссылок нужно конфигурировать вручную. В случае использования службы DNS в локальной сети этот файл можно отредактировать или заменить аналогичными записями, указывающими внутренние корневые DNS-серверы. Более того, на компьютере, который управляет корневым DNS-серве- ром, вообще не нужно использовать корневые ссылки. В этом сценарии Windows Server 2008 автоматически удаляет файл корневых ссылок Cache.dns.
Пример запроса
В следующем примере продемонстрирован запрос DNS. Клиент запрашивает предпочтительный DNS-сервер, который затем выполняет рекурсию, запрашивая DNS-серверы, расположенные выше в иерархии. Предполагается, что кэши DNS-клиента и всех DNS-серверов пусты.
Ниже описан процесс обработки запроса службой DNS-клиент на клиентском компьютере.
1. Клиент связывается с сервером NameServer1 и запрашивает example.wikipedia.org.
2. Сервер NameServer1 проверяет свой кэш и зоны. Если ответ не получен, он обращается к главному серверу Интернета (т. е. корневому серверу) и запрашивает example.wikipedia.org.
3. Корневой сервер Интернета не знает ответ и запрашивает направление на главный сервер домена .org.
4. Сервер NameServer1 обращается к главному серверу домена .org и запрашивает имя example.wikipedia.org.
5. Главный сервер домена .org не знает точный ответ и направляет запрос на главный сервер домена wikipedia.org.
6. Сервер NameServer1 обращается к главному серверу домена wikipedia.org и запрашивает имя example.wikipedia.org.
7. Главный сервер домена wikipedia.org знает ответ и отправляет запрашиваемый IP-адрес.
8. Сервер NameServer1 отправляет в ответе на запрос клиента IP-адрес узла
example.wikipedia.org..
Кэширование
Кэширование поддерживают обе службы — DNS-клиент и DNS-сервер. Кэширование повышает производительность DNS и значительно снижает уровень трафика запросов DNS в сети.
Кэш DNS-клиента
Кэш DNS-клиента еще называют кэшем распознавателя DNS. При каждом запуске службы DNS-клиент все сопоставления имен в IP-адреса, содержащиеся в статическом файле Hosts, предварительно загружаются в кэш распознавателя DNS. Файл Hosts находится в папке WINDOWS\System32\Drivers\Etc.
ПРИМЕЧАНИЕ:
Использование файла Hosts
Каждая запись, добавляемая в файл Hosts, немедленно загружается в кэш распознавателя DNS.
Помимо записей в файле Hosts кэш распознавателя DNS также включает записи, получаемые клиентом в ответ на запросы DNS-серверов. Каждый раз при остановке службы DNS-клиент (DNS Client) выполняется очистка кэша распознавателя DNS.
Кэш DNS-сервера
Поскольку DNS-серверы выполняют рекурсивные запросы от лица клиентов, они временно кэшируют записи ресурсов. Эти кэшированные записи содержат информацию, получаемую в ответах на запросы от лица клиента. Позже, при получении новых запросов информации, соответствующей кэшированным записям ресурсов, DNS-сервер может использовать кэшированную информацию для ответа на эти запросы.
Очистка кэша DNS-сервера выполняется каждый раз при остановке службы DNS-сервера. Очистку кэша DNS-сервера можно выполнить и вручную в консоли DNS (инструмент, используемый для администрирования DNS), щелкнув правой кнопкой мыши значок сервера в дереве консоли и применив команду Очистить кэш (Clear Cache). Наконец, кэш сервера можно очистить, запустив в командной строке команду Dnscmd/clearcache.
Значения Time To Live (TTL)
Время жизни датаграммы в секундах применяется ко всем кэшированным записям ресурсов в кэше распознавателя DNS и кэше DNS-сервера. Во время жизни TTL кэшированного ресурса распознаватель или сервер DNS может использовать эту запись для ответа на запросы. По умолчанию назначается значение TTL 3600 с (1 ч), однако этот параметр можно изменять на уровнях зоны и записи.
The Windows operating systems, both client and servers, will always prefer resolving names by the well-known DNS process. However, if a searched name is not present the in the DNS zones, the local client will progress to the three alternative methods:
Link-Local Multicast Name Resolution: UDP/5355
MulticastDNS: UDP/5353
NetBIOS name broadcast: UDP/137
The full details of these protocols could be found in this article.
All of these protocols have the common characteristics that they are designed for name resolution primarily in home networks. Inside isolated boundaries, they provide an easy and useful ability for various smart-TVs, audio speakers, and other equipment to connect to each other.
However, in an enterprise environment, the protocols present potential risks.
The name queries are sent to all devices on the local subnet, and any device can reply to any question, legit or not. There is no authentication or verification possible on the incoming reply. The client or server will believe whatever name reply it is being fed from the anonymous network. This presents an option for a malicious user to stage, e.g., man-in-the-middle attacks.
If an administrator desires to have the clients and servers solely rely on DNS lookups, the decision could be made to disable the local name resolution methods.
How to disable LLMNR:
LLMNR was added in Windows Server 2008 and Windows Vista.
How to verify the current status of LLMNR of the system:
Open a classical Command Prompt (CMD) and run the following command:
reg query "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" | FIND /i "EnableMulticast"If you receive no output, LLMNR is active. If you receive output with the value 0x1, LLLMNR is also active.
Additional method to verify if LLMNR is enabled:
netstat -nao | FIND /i ":5355 "If you see a listening port on UDP/5355, LLMNR is active on the machine.
LLMNR is the easiest method to remove. The protocol can be disabled by a Group Policy Setting:
Computer\Policies\Administrative templates\Network\DNS Client
Turn off multicast name resolution: ENABLED
How to disable MulticastDNS:
How to verify if MulticastDNS is currently running on the system:
Open a classical Command Prompt (CMD) and run the following command:
reg query "HKLM\System\CurrentControlSet\Services\DNScache\Parameters" | FIND /i "EnableMDNS"If you receive no output, MulticastDNS is active. If you receive output with the value 0x1, MulticastDNS is also active.
Additional method to check if mDNS is running on a system:
netstat -nao | FIND /i ":5353 "If you see a listening port on UDP/5353, mDNS is active on the machine.
MulticastDNS, being very recently added to the Windows Server 2019 and 2022 operating systems, does not have a managed Group Policy to disable the protocol.
At system boot, the server will check for the presence of a specific registry value:
HKLM\System\CurrentControlSet\Services\DNScache\Parameters\EnableMDNS
If this value does not exist, the server will assume that mDNS should be running. By default, this entry will not be present, meaning the server will automatically load mDNS.
By adding the registry entry EnableMDNS will the value of 0, the system will not load mDNS. Note that this is only checked at system boot.
The best option to disable mDNS is to define the registry value through Group Policy Preferences.
Use the action of “Update”, the hive as “HKEY_LOCAL_Machine” and the Key Path:
System\CurrentControlSet\Services\DNScache\Parameters
The value must be called:
EnableMDNS
The value type is REG_DWORD and the actual value data set to zero.
How to disable NetBIOS name resolution broadcasts:
NetBIOS is the oldest local name resolution option still available. It is also the method that is slightly more complicated to disable.
How to verify if NetBIOS is currently running on a system:
Open a classical Command Prompt (CMD) and run the following command:
ipconfig /all | FIND /i "netbios"Additional method to verify if NetBIOS is active:
netstat -nao | find /i ":137 "If you see the UDP port listed, NetBIOS broadcast name resolution is enabled.
Note, that when disabling NetBIOS name resolution, you will also disable the listening port TCP/139. This port was used to host the file server service (SMB) before the release of Windows 2000. After this, the default port for SMB is TCP/445. However, for backwards compatibility, e.g., with clients potentially running Windows 95, the TCP/139 is still enabled on all systems. Historically, many security vulnerabilities have been present on the NetBIOS TCP/139 port.
There are three main options to disable NetBIOS.
Option 1 to disable NetBIOS:
For clients receiving their TCP/IP configuration through DHCP, a convenient option is available.
On the Microsoft DHCP server, open the scope, right click Scope Options – Configure Options – Advanced – “Microsoft Windows 2000 Options” in the “Vendor class” list.
Set the “001 Microsoft Disable Netbios Option” to the value “0x2”.
This method is an effective option to remove NetBIOS for client computers.
Option 2 to disable NetBIOS:
For non-DHCP systems, i.e., often servers, NetBIOS could be manually removed through the graphical interface.
Disable NetBIOS through the network interface properties:
TCP/IPv4 properties – Advanced – WINS – Disable NetBIOS over TCP/IP
Option 3 to disable NetBIOS:
To disable NetBIOS programmatically is more difficult. This is due to the fact of NetBIOS storing the values in the registry under each unique Network Interface Card GUID.
HKLM\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces
Due to each interface having a randomized and globally unique GUID, the final path is not predictable.
With systems with multiple NICs, the GUID for each interface card can be retrieved with the Powershell command:
Get-NetAdapter | Format-List -Property name,DeviceIDSet the registry value:
HKLM\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip_{guid}\netbiosoptions = 2
SUMMARY:
To verify the before and after state, use a classical Command Prompt (CMD) and run the following commands:
netstat -nao | FIND /i ":137 "
netstat -nao | FIND /i ":5353 "
netstat -nao | FIND /i ":5355 "If you receive any output, the local name resolution methods are still enabled.
If receiving no output, the three local name protocols are now disabled.
Windows Server 2008 – DNS
The principles for DNS in Windows Server 2008 are much the same as they were for Windows Server 2003.
Active Directory absolutely requires DNS. In particular, Active Directory relies on DNS to find resources such as Global Catalog and Kerberos. In Windows Server 2008, DNS combines support for standard DNS protocols with the benefits of integration with Active Directory Domain Services (AD DS).
DNS enables we humans to use meaningful names such as ‘BigServer’ instead of pure dot decimal IP addresses. (Or colon hex numbers for IPv6). The DNS server responds to requests from clients such as XP or Vista to provide the IP address associated with a mail or web server’s DNS domain name. The beauty of DNS is that it’s scaleable because the domain names can be organized into a hierarchy.
♦
Practical Tasks for DNS in Windows Server 2008
Your first decision is one of approach. Do you take the simplistic approach? In which case accept the defaults and go with the simple choices. When you create a Domain Controller (see Add roles) it is automatically configured to use the appropriate DNS servers for name resolution.
This method either works incredibly easily, or else it goes spectacularly wrong; in which case you have to go back to the drawing board, and probably you should ask for guidance from someone who has installed and configured DNS before.
The other approach is to practice with DNS on a test network, have one hand on the keyboard and the other hand thumbing a text book.
For both approaches, the first task is plan your names. What will be the name of your Active Directory domain? Will it be the same name as your DNS domain?
The second task is to install the DNS service. Start with the Server Manager, and the Add roles and let the wizard install and configure the DNS role.
Wherever possible choose Active Directory Integrated DNS. Microsoft Active Directory, working with Microsoft DNS must be better than mixing Microsoft AD with UNIX DNS.
Mr Average and Mr In-a-Hurry do not need to study DNS in depth. It’s near enough the same as DNS in Windows Server 2003. The main thing to know is that Microsoft’s Windows Server 2008 DNS is compliant with RFC (Refer For Comments) standards, for example RFC 2136 for Dynamic DNS.
Guy Recommends: The Free Config Generator
SolarWinds’ Config Generator is a free tool, which puts you in charge of controlling changes to network routers and other SNMP devices. Boost your network performance by activating network device features you’ve already paid for.
Guy says that for newbies the biggest benefit of this free tool is that it will provide the impetus for you to learn more about configuring the SNMP service with its ‘Traps’ and ‘Communities’. Try Config Generator now – it’s free!
Download your free copy of Config Generator
What’s New In Windows Server 2008’s DNS
IPv6
The best feature of DNS in Windows Server 2008 is that it’s ready for IPv6. For example it can handle the 32 hex digits in the IP address. Furthermore it employs the quad-A (AAAA) resource records for forward name resolution. While reverse lookup is handled by the new IP6.ARPA domain.
RODC
You may have read else where about the new Windows Server 2008 RODC Read Only Domain Controller. The implications for DNS are that these servers hold a read only copy of the ForestDNSZones, and DomainDNSZones.
LLMNR
Link-local multicast name resolution is an intelligent system whereby Vista clients and W2K3 member servers can resolve names on the local subnet even when the DNS server is down.
This is a new way for Vista clients to contact their local Domain Controller. Principally a mechanism for laptops. With XP laptops could get ‘locked on’ to a distant server, when the laptop returns to base it still fixates on the distant DC. With Vista, it occasionally tries to find the nearest DC, thus breaking an inappropriate 20 hop link with a distant DC when there is a perfectly good Domain Controller in the same building.
Dynamic Updates
Windows Server 2008 loads Active Directory in the background, this helps DNS servers with zillions of records who reboot often. While this is progress, I wonder how common that scenario of frequent reboots and lots of zone records is?
GlobalNames Zone (GNZ)
Is a way of incorporating WINS resolution within DNS. My mate ‘Mad’ Mick says, ‘Those bright enough to figure out GlobalNames are bright enough to have phased out WINS’. However, if you are a techie genius who is weighted down by old applications that rely on NetBIOS over TCP/IP then you can add appropriate single-label records as CNAME records in DNS. The idea of GlobalNames is to replace the static WINS records for mail servers or possibly web servers.
Should you need to experiment with GlobalNames, then you need to create a particular zone, this is how you perform the action from the command-line:
Dnscmd ServerName /config /Enableglobalnamessupport 1
Alternatively, you could use the DNS GUI and create a zone called precisely: GlobalNames (not case sensitive).
Once you have created this special zone called GlobalNames, then add CNAMES which point to the FQDN of the appropriate mail or web server.
»
Useful DNS Features First Introduced in W2K3 (Windows Server 2003)
DNS Integrated with Active Directory
The biggest breakthrough with DNS was to integrate its database with that of Active Directory. This made it much easier to replicate. This integration started in Windows 2000 and there have been minor advancements in Windows Server 2003 and now in Server 2008. e.g RODC, Security and new site location flags.
DNS Stub Zones
A stub zone holds a copy of only the resource records that are necessary to identify the authoritative (child) DNS servers for that zone. The idea is to help maintain DNS name-resolution efficiency.
Dynamic Update Protocol
Clients such as XP and Vista can tell the DNS Server service to dynamically update their resource records. Dynamic DNS (DDNS) introduces the one good feature of WINS into DNS. The result is no need to manually update DNS ‘A’ Host records.
Incremental Zone Transfer (IXFR)
These days we take for granted the idea of only updating records that have changed. However, back in NT 4.0 days one change in a host record resulted the whole of the DNS database being replicated. Very inefficient.
Conditional forwarders
Here is another efficient idea if the server does not have a record for a specific domain, it forwards the request onto a server that is authoritative for that domain. Requests for other domains would not be treated in this way, hence Conditional Forwarding.
If you like this page then please share it with your friends
Microsoft Windows Server 2008 Topics:
• Server 2008 Home • Overview • What’s New? • Migration Advice • Install • SP1 Review
• AD DC • Roles • Features • Editions • Hyper-V • UAC • IPv6 • Group Policy • Free NPM Trial