Troubleshoot DNS name resolution on the Internet in Windows Server

This article provides methods to troubleshoot Domain Name System (DNS) name resolution on the Internet in Microsoft Windows Server.

Original product version: В Windows Server 2012 R2
Original KB number: В 816567

Summary

This article describes methods that you can use to configure DNS if queries that are directed to the Internet are not resolved correctly, but local intranet name resolution functions correctly.

The Cache.dns file that stores root hints on your Windows Server computer may be missing or damaged. You can manually add root hints by using the DNS snap-in, replace the Cache.dns file on your hard disk with the backup Cache.dns file or replace it with the original version of the Cache.dns file.

To update root hints by using the DNS snap-in

To update root hints:

On a non-domain controller

To manually add root hints on a Windows Server DNS server that is not configured as a domain controller:

1. Click Start, point to Administrative Tools, and then click DNS.
2. In the right pane, right-click ServerName, where ServerName is the name of the server, and then click Properties.
3. Click the Root Hints tab, and then click Add.
4. Specify the fully qualified domain name (FQDN) and the IP address of the root server that you want to add, and then click OK.

On a domain controller

To update root hints on a Windows Server DNS server that is configured as a domain controller:

1. Click Start, point to Administrative Tools, and then click DNS.
2. In the right pane, right-click ServerName, where ServerName is the name of the server, and then click Properties.
3. Click the Root Hints tab.
4. Do one of the following:
   • Add a root server to the list. To do so, click Add, specify the FQDN and the IP address of the root server that you want to add, and then click OK.
   • Copy the root hints from another DNS server. To do so, click Copy from Server, specify the IP address of the DNS server where you want to copy the root hints from, and then click OK.
5. Click OK.

The following is a list root servers as specified by Network Solutions:

Microsoft TCP/IP Host Name Resolution Order

Summary

This article discusses the different methods of host name to IP address resolutions used by Microsoft Windows clients. The sequence of methods is different than the sequence used to resolve NetBIOS names to IP addresses.

More Information

On a network using the TCP/IP protocol, it is necessary to convert names of resources to IP addresses to connect to these resources. Microsoft Windows clients will follow a sequence of methods in attempting to resolve a name to an address, stopping the search when it successfully matches a name to an IP address.

There are two main sequences used in almost all cases: NetBIOS resolution and Host name resolution. Clients connecting to resources on Microsoft servers, typically through Windows File Manager or Network Neighborhood, most often use NetBIOS name resolution.

For additional information, please see the following article in the Microsoft Knowledge Base:

119493 NetBIOS over TCP/IP Name Resolution and WINS

Host name resolution resolves the names of TCP/IP resources that do not connect through the NetBIOS interface. The most common example of this is a Web browser such as Microsoft Internet Explorer. Other examples include Internet applications such as Ping, FTP, and Telnet. Many modern database and mail applications that connect using Winsock, the Microsoft Windows implementation of TCP/IP sockets, also use host name resolution. Examples of these types of applications are Outlook and Exchange.

When troubleshooting name resolution issues, it is important to narrow down whether the application is resolving a NetBIOS name or a host name.

NOTE: In the context of this article, the term «client» does not necessarily refer to a workstation. A Windows NT server will take the role of client when it requires access to resources that require host name resolution.

Host name resolution generally uses the following sequence:

The client checks to see if the name queried is its own.

The client then searches a local Hosts file, a list of IP address and names stored on the local computer.

NOTE: The Hosts file location depends on the operating system:

Windows NT %Systemroot%\System32\Drivers\Etc
Windows 95 \
Windows for Workgroups \
Windows 3.1 \
MS-Client 3.0 \Net
Lan Manager 2.2c Client \Net
Where %Systemroot% is the folder in which Windows NT is installed, is the drive on which the OS is installed, and refers to a boot floppy disk or drive C.

A sample hosts file, Hosts.sam, is installed with the TCP/IP protocol showing the proper format.

Domain Name System (DNS) servers are queried.

If the name is still not resolved, NetBIOS name resolution sequence is used as a backup. This order can be changed by configuring the NetBIOS node type of the client.

The Windows client will try each of these methods until it either successfully resolves the name or exhausts these methods. Windows NT, Windows 95, and Windows for Workgroups clients using Microsoft TCP/IP 3.11b follow this sequence. Lan Manager 2.2c or Microsoft Client 3.0 clients will not use NetBIOS name resolution as a backup.

For additional information, please see the following articles in the Microsoft Knowledge Base:

169141 NetBIOS and hostname resolution for MS-Client and LM 2.2c
When resolving names the client will skip methods for which it is not configured. For example, if there is no hosts file on the system, then it will skip step #2 above and try a query to a DNS server. If no DNS server IP addresses are entered in the client TCP/IP configuration, then the client will skip to the next step in the sequence after DNS.

The method for changing host name resolution order differs among operating systems and versions. These are documented in the Resource Kits for the specific operating systems, as well as in the Microsoft Knowledge Base.

For additional information, please see the following articles in the Microsoft Knowledge Base:

171567 Windows NT 4.0 ServiceProvider Priority Values Not Applied

139270 How to Change Name Resolution Order on Windows 95 and Windows NT

119372 Setting the Name Resolution Search Order for TCP/IP-32

Troubleshooting

Problem: Client is unable to resolve a host name.

If a client cannot resolve a host name, then it is best to verify the Host name resolution sequence listed above that the client should be using. If the name does not exist in any of the resources that the client uses, then you must decide to which resource to add it. If the name exists in one of the resources, such as a DNS server or a Windows Internet Name Service (WINS) server and the client is not resolving the name correctly, focus your attention on troubleshooting that specific resource.

Also, confirm that the client is trying to resolve a host name and not a NetBIOS name. Many applications have multiple methods that they can utilize to resolve names, this is especially true of mail and database applications. The application may be configured to connect to resources using NetBIOS. Depending on the client configuration the client may bypass host name resolution. From there it will be necessary to either change the connection type to TCP/IP sockets or to troubleshoot the problem as a NetBIOS issue.

Problem: Client resolves a name very slowly, or fails to resolve a name and takes a long time to report a failure.

Having DNS servers configured in a client’s TCP/IP configuration, but the server is not available to the client usually causes this. Because the TCP/IP protocol assumes an unreliable network, a client will repeatedly attempt to connect to a DNS server before abandoning the attempted query. The client will then attempt to query a second DNS server if one is configured and take the same time to fail. Only then will the client step through to NetBIOS name resolution as described above.

There are three ways to approach this issue.

If the host name is correctly entered in a host file, it will be resolved before the client attempts to query DNS. This solution works well if DNS servers are temporarily unreachable and there is a small number of host names that need to be resolved . Manually configuring Hosts files for numerous clients may be prohibitive. -or-

If DNS servers are available, but the DNS Server addresses in the clients TCP/IP configuration are incorrect, then correcting these addresses will allow the clients to contact the DNS servers immediately. Even if a DNS server reports that it cannot resolve a name, this will happen much faster than if the client cannot reach a DNS server at all. -or-

If DNS servers are configured on the client, but these servers are permanently unavailable, then remove the IP addresses of the DNS servers from the client configuration. The client will then bypass the DNS lookup without delay. -or-

If records in the DNS database are missing or incorrect, then there will be a delay as DNS servers query other DNS servers before reporting that they cannot resolve the name. This will usually cause a delay of just a few seconds.

For additional information on TCP/IP and name resolution, please see the following white paper available on the Microsoft anonymous ftp server:

Domain name resolution (Русский)

Доменное имя — символьное представление IP-адреса в системе доменных имён (Domain Name System, DNS). В статье рассмотрена настройка разрешения (resolution) доменных имён.

Contents

Name Service Switch

Name Service Switch (NSS) — функциональность стандартной библиотеки Си ( glibc ), на основе которой выполняется разрешение доменных имён при вызове getaddrinfo(3) . NSS объединяет управление базами данных различных служб, позволяя настраивать порядок поиска в этих базах с помощью файла nsswitch.conf(5) . За разрешение доменных имён отвечает база данных hosts, для которой glibc предлагает следующие службы:

systemd предоставляет три службы NSS для разрешения имён:

• nss-resolve(8) — кэширующий распознаватель-заглушка DNS, подробнее в статье systemd-resolved;
• nss-myhostname(8) — разрешение имён без редактирования /etc/hosts , подробнее в статье Настройка сети#Разрешение имён в локальной сети;
• nss-mymachines(8) — разрешение имён для локальных контейнеров systemd-machined(8) .

Разрешение доменных имён с NSS

Базы данных NSS можно опрашивать утилитой getent(1) . Разрешение доменного имени через NSS выполняется следующим образом:

Распознаватель glibc

Распознаватель glibc считывает файл /etc/resolv.conf при каждом разрешении имени, определяя сервер доменных имён и используемые опции.

В файле resolv.conf(5) перечислены сервера имён и настройки. Сервера используются в порядке перечисления, сверху вниз. Можно указать до трёх серверов. Строки, начинающиеся с символа решётки ( # ), игнорируются.

Перезапись файла /etc/resolv.conf

Сетевые менеджеры иногда перезаписывают файл /etc/resolv.conf . Подробности можно найти в соответствующих статьях:

Помешать программам изменять файл /etc/resolv.conf можно с помощью защиты от записи, атрибутом неизменяемости:

Ограничение времени поиска

Если поиск выполняется слишком медленно (например, при работе pacman или в браузере), попробуйте задать тайм-аут с небольшим значением. По истечении тайм-аута распознаватель выбирает следующий сервер имён из списка. Добавьте следующую строку в /etc/resolv.conf :

Задержка при разрешении имени с IPv6

Из-за неправильной настройки DNS-сервера или межсетевого экрана может возникать пятисекундная задержка при попытке выполнить разрешение имени двумя запросами, A и AAAA [1]. Добавьте следующую опцию в /etc/resolv.conf , чтобы решить проблему:

Имена в локальном домене

Чтобы имена локальных хостов можно было указывать без доменного имени, добавьте следующую строку в файл /etc/resolv.conf (домен замените на необходимый):

Теперь при работе, например, ssh можно сослаться на локальный хост строкой вида mainmachine1 (вместо mainmachine1.example.org ); в то же время другим командам (например, drill) всё ещё может требоваться полное имя домена.

Утилиты

С помощью специализированных DNS-утилит можно отправлять запросы конкретным DNS-серверам и/или запросы к записям DNS/DNSSEC определённого типа. NSS при этом не используется, поскольку в утилитах такого рода обычно имеется собственная реализация протокола DNS.

Например, для сбора DNS-информации можно использовать утилиту drill(1) из пакета ldns . Следующая команда запросит TXT-запись домена у указанного сервера имён:

Если DNS-сервер не указать, то drill будет отправлять запросы одному из указанных в /etc/resolv.conf серверов.

Производительность

В распознавателе glibc отсуствует кэширование ответов. Если кэширование всё же необходимо, то либо используйте systemd-resolved, либо запустите локальный кэширующий DNS-сервер. Во втором случае сервер будет работать как локальный сервер имён — добавьте адреса 127.0.0.1 и ::1 в файл /etc/resolv.conf (или в /etc/resolvconf.conf при работе через openresolv).

Приватность и безопасность

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

Если вы всё же рассчитываете на некоторую конфиденциальность, то в первую очередь необходимо выбрать DNS-сервер, которому можно доверять. Сервера имён предоставляются как интернет-провайдерами, так и сторонними компаниями. Также можно запустить собственный рекурсивный сервер имён, но это, само собой, потребует некоторых дополнительных усилий. Если вы используете DHCP-клиент в недоверенной сети, убедитесь, что ваш распознаватель настроен на использование статических серверов, потому что иначе запросы будут отправляться на неизвестный посторонний сервер. Обезопасить соединение с удалённым DNS-сервером можно с помощью шифрования по протоколам DNS over TLS (RFC 7858), DNS over HTTPS (RFC 8484) и DNSCrypt, при условии, что и выбранный upstream-сервер, и ваш распознаватель одновременно поддерживают конкретный протокол. В качестве отдельного решения можно использовать специализированную программу для шифрования соединяний, — например, stunnel. Для проверки подлинности ответов (в самом ли деле они приходят от авторитативного сервера имён) можно использовать DNSSEC (опять же при условии, что он поддерживается и сервером, и вашим распознавателем).

DNS в приложениях

Некоторые клиентские программы, например, крупнейшие веб-браузеры, начали реализовывать DNS over HTTPS [2], [3]. С одной стороны, шифрование сообщений является неоспоримым плюсом; в то же время такие программы часто отправляют запросы «мимо» системного распознавателя [4].

Firefox предоставляет настройки для включения/отключение DNS over HTTPS и выбора сервера имён.

Chromium включает DoH, если сервера имён, используемые системным распознавателем, его поддерживают. Подробнее (в т.ч. о том, как отключить DoH) см. этот пост.

Также разработчики Mozilla предложили отключать DNS в приложениях, если системный распознаватель не может выполнить разрешение имени специального домена use-application-dns.net . В настоящее время эта проверка реализована только в Firefox.

Oblivious DNS

Oblivious DNS — система распознавания DNS-имён, которая призвана решить некоторые проблемы приватности. Подробнее см. статью Cloudflare.

Сторонние службы DNS

Существует целый DNS-служб от независимых производителей; для некоторых из них также разработаны специализированные программы.

С помощью dnsperftest можно замерить производительность наиболее популярных распознавателей для вашего географического расположения. На сайте dnsperf.com приведено глобальное сравнение производительности резличных провайдеров.

DNS-серверы

DNS-серверы делятся на авторитативные и рекурсивные. Если сервер не принадлежит к одному из этих двух типов, то он представляет из себя так называемый распознаватель-заглушку (stub resolver); его назначение — просто перенаправлять запросы к некоему рекурсивному серверу имён. Заглушки обычно используются для DNS-кэширования на хосте или в локальной сети. Обратите внимание, что то же самое можно получить и установив полноценный сервер имён. В данном разделе представлено сравнение доступных DNS-серверов, более подробное сравнение можно найти в стетье Comparison of DNS server software.

Название	Пакет	Возможности				resolvconf	Поддерживаемые протоколы
		Авторитативный	Рекурсивный	Кэш	Проверка DNSSEC		DNS	DNSCrypt	DNS over TLS	DNS over HTTPS
BIND	bind	Да	Да	Да	Да	Да	Да	Нет	stunnel#DNS over TLS	Нет
CoreDNS	corednsAUR или coredns-binAUR	?	?	?	?	?	?	?	?	?
Deadwood (MaraDNS recursor)	maradnsAUR	Нет	Да	Да	Нет	Нет	Да	Нет	Нет	Нет
dnscrypt-proxy	dnscrypt-proxy	Нет	Нет	Да	Нет	Нет	Сервер	Распознаватель	Нет	Да
dnsmasq	dnsmasq	Частично 1	Нет	Да	Да	Да	Да	Нет	Нет	Нет
Knot Resolver	knot-resolver	Нет	Да	Да	Да	Нет	Да	Нет	Да	Сервер
pdnsd	pdnsd	Да	Да	Стойкий	Нет	Да	Да	Нет	Нет	Нет
PowerDNS Recursor	powerdns-recursor	Нет	Да	Да	Да	Да	Да	Нет	Нет	Нет
Rescached	rescached-gitAUR	Нет	Нет	Да	Нет	Да	Да	Нет	Нет	Ограниченно 2
SmartDNS	smartdns	Нет	Нет	Да	Нет	?	Да	Нет	Распознаватель	Распознаватель
Stubby	stubby	Нет	Нет	Нет	Да	Нет	Сервер	Нет	Распознаватель	Нет
systemd-resolved	systemd	Нет	Нет	Да	Да	Да	Распознаватель и сервер (ограниченно)	Нет	Распознаватель	Нет
Unbound	unbound	Частично	Да	Да 3	Да	Да	Да	Сервер	Да	Сервер

1. Из Википедии: dnsmasq имеет ограниченную поддержку авторитативности, предназначенную главным образом для внутренних сетей, а не открытого Интернета.
2. Только перенаправление, если сам Rescached получил DoH-запрос [5].
3. Unbound может использовать Redis в качестве бэкэнда для стойкого кэширования.

Авторитативные серверы

Название	Пакет	DNSSEC	Географическая балансировка
gdnsd	gdnsd	Нет	Да
Knot DNS	knot	Да	Да
MaraDNS	maradns AUR	Нет	?
NSD	nsd	Нет	Нет
PowerDNS	powerdns	Да	Да

Условное перенаправление

Существует возможность настроить систему на использование определённого DNS-распознавателя для разрешения некоторых доменных имён. Например, очень удобно при подключении к VPN-сети запросы к ней же разрешать с помощью её собственного DNS, в то время как запросы к остальному интернету будут по прежнему разрешаться стандартным распознавателем. Также это можно использовать в локальных сетях.

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

В динамическом окружении (ноутбуки и в некоторой степени настольные компьютеры) необходимо настроить ваш распознаватель на основе сети(-ей), к которой(-ым) вы подключены. Проще всего это сделать с помощью openresolv, поскольку он поддерживает нескольких абонентов. Некоторые сетевые менеджеры также поддерживают этот механизм, либо через openresolv, либо через настройку распознавателя напрямую. Так, в NetworkManager реализовано условное перенаправление без openresolv.