Translate

тест скорости интернета

суббота, 23 июня 2012 г.

Настройка параметров DNS

Инфраструктура 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-клиент (ComputerConfiguration\Administrative Tools\Network\DNS 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'sAddresses 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 DNSRegistration). Чтобы включить этот параметр, нужно  вначале включить параметр Зарегистрировать адреса этого подключения в DNS (Register This Connection'sAddresses In DNS). Наконец, для успешного  обновления PTR-записи в среде доменных служб Active Directory предпочтительный DNS-сервер клиента должен управлять соответственно отконфигурированными зонами прямого и обратного поиска.
ПРИМЕЧАНИЕ: Регистрация имен подключений с помощью групповой политики
Чтобы компьютеры в сети регистрировали имена DNS подключений, можно использовать групповую политику. В объекте групповой политики откройте папку Конфигурация компьютера\Административные шаблоны\Сеть\DNS-клиент (Computer Configuration\Administrative Tools\Network\DNS 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).

12 комментариев:

  1. Александр, спасибо за статью. У меня есть проблема, для которой я пока не нашёл решения. Буду благодарен, если подскажите или направите в правильном направлении.

    Физическая машина находится в домене и сидит за проксёй. На этой машине развёрнута виртуалка (на Vmware Workstation 8) WinServer2008R2 со своим доменом. Тип подключения - NAT, внутренний IP виртуалки 10.0.0.3. На ней поднят AD, DHCP (10.0.0.3) и DNS. Её шлюз 10.0.0.2. При параметрах подключения этой виртуалки
    IP 10.0.0.3
    255.255.255.0
    DG 10.0.0.2
    DNS 10.0.0.2 интернет на этой машине есть. Прокси реального домена запрашивает логин/пароль от реальной доменной учётки. При этом сама прокся из виртуалки не пингуется, но её DNS имя резолвится. Однако при таком подключении не резолвятся имена клиентов, входящие в виртуальный домен по полному имени (с DNS суффиксом).

    Если я меняю в подключении DNS на 10.0.0.3, то пинг до виртуальных клиентов проходит по полному имени (с DNS-суффиксом), но:
    1. Перестаёт резолвится DNS прокси. Пинг по IP до неё так и не проходит.
    2. Пропадает интернет, хотя имена самих сайтов, (внимание!) резолвятся. Как такое может быть, если DNS, по идее, не должен их резолвить? Или я не прав?

    Мне необходимо, чтобы И был интернет, И чтобы имена клиентов в этом домене резолвились с днс-суффиксами. Не могу понять в чём проблема. Спасибо, даже если дочитали до конца.

    ОтветитьУдалить
    Ответы
    1. Я рад, что статьи, которые публикую здесь, пригождаются не только мне! :-)
      В Вашем случае мне не все понятно:
      1. 10.0.0.0/24 - виртуальная подсеть, а где реальная?
      2. Как домены связаны между собой?

      Думаю, в Вашем случае, надо посмотреть:
      1. Отношения доверия между доменами (если необходимо использовать из одного домена ресурсы другого - например, доступ к ресурсам общего доступа);
      2. Проверить адресные пространства реального и виртуального доменов - адреса и маски. Подозреваю, что адресные пространства не пересекаются (так довольно часто и делают), поэтому в реальный надо настроить форвардинг DNS. Если же пространства пересекаются - все находится в одной подсети, то это удобства может не добавить... хотя... иногда может и упростить несколько все процедуры...

      В Вашем случае самый простой способ решить проблему с резолвом - сделать форвард (или односторонний или двусторонний - в зависимости от того, как надо).
      Или еще вариант - разрешить реплицировать зоны между DNS-серверами.
      Ну и главное - нарисовать карту сети и проверить таблицу маршрутизации! ;-)

      Это то, что сразу пришло в голову на основе имеющихся данных и моих предположений.

      P.S.: NAT может свои шутки устраивать (но это уже риторика). :-)

      Удалить
  2. Спасибо за быстрый ответ :) Отвечая на Ваши вопросы:

    1. В моём случае реальная и виртуальные подсети не пересекаются между собой. Реальная машина имеет:
    10.16.8.X (автоматически)
    255.255.252.0
    DG 10.16.8.1
    2. Никак. Это просто виртуальный домен, находящийся за натом. Они про друг друга ничего не знают.

    По поводу форварда DNS: Вы имеете ввиду на виртуалке в свойствах роли DNS DC на вкладке Forwarders прописать IP DNS? Если да, то какой это должен быть IP? Default Gateway 10.0.0.2 или DNS, используемый реальной машиной?

    Мне хочется понять, почему когда я ставлю на виртуалке DNS 10.0.0.3 в свойствах подключения, то имена внешних сайтов (ya.ru, например) резолвятся, а имена внутренних ресурсов в реальном домене (прокси) - нет. Ведь виртуальный сервер, по идее, не должен знать, куда отправлять ДНС запросы, если я специально это нигде не прописывал. Либо я до конца не понял, как работает ДНС.

    ОтветитьУдалить
    Ответы
    1. Пожалуйста. :-)
      В вашем случае основной затык в маршрутизации - запросы уходят по default route - надо его проверять.
      Сейчас еще раз пересмотрел комментарии - у Вас DNS на контроллере домена, а его адрес 0.3, Вы же отправляете запросы на 0.2 (default gateway)... Вот здесь и проблема! ;-)
      DNS у Вас должен стоять 0.3, тогда локальные клиенты будут резолвиться, а все остальное отправлять во вне через форвард.
      Так же такую ситуацию можно разрешить так (как пример):
      1. defaut gw - 0.3, metric 3
      2. gw - 0.2, metric 4
      - Задать шлюзы и назначить им приоритеты. На такую конфигурацию винда обычно ругается, но работает.
      Советую проверить еще таблицы маршрутизации для успокоения души. :-)
      Если нет необходимости резолвить внешние машины через DNS и цепляться к ним по DNS-именам или подключаться к DFS, то DNS можно и не трогать - в Вашем случае вопрос с доступом к локальным машинам и интернет должен решиться маршрутизацией.
      Ну а DNS - это как дополнительная фишка, которую можно разрулить форвардом, доверительными отношениями и репликацией. Главное - маршрутизация.

      Удалить
    2. Александр, всё верно. Если я ставлю ДНС 0.3, то машины в виртуальном домене резолвятся (я вначале об этом писал), но интернета нету. В такой конфигурации также не резолвится имя прокси, которая в реальном домене. Что тоже в целом понятно. А как вы думаете, почему в такой конфигурации резолвятся имена внешних ресурсов? Откуда ДНС 10.0.0.3 может брать их имена, если я сам не настраивал форвадинг? Хочется понять, как это работает.

      UPDATE:
      На сервере сейчас:
      IP 10.0.0.3
      255.255.255.0
      DG 10.0.0.2
      DNS 10.0.0.3

      В настройках DHCP:
      003 10.0.0.2
      006 10.0.0.3
      015 мой.домен

      В настройках DNS во вкладке Forwarding указал 10.0.0.2. Если это убрать, то пропадает инет.

      В результате:
      интернет есть и на сервере, и на клиентах
      имя прокси резолвится
      С клиентов могу пинговать сервер по полному имени (с днс-суффиксом)
      С сервера НЕ могу пинговать клиентов по полному имени. Как это можно вылечить?

      Маршрутизация: 0.0.0.0 0.0.0.0 10.0.02 10.0.0.0.3

      В любом случае спасибо. Вы и так помогли.

      Удалить
    3. UPDATE 2. Перезагрузил сервак и тестируемую машину - всё заработало.

      P.S. в процессе настройки я также столкнулся с проблемой, когда при такой конфигурации не работал интернет. При попытки пинга любого внешнего узла получал Destination host unreachable. В итоге дело оказалось в самой винде. Если кто-то столкнулся с подобной проблемой, проверьте, что в ключе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\*\ в параметре DefaultGateway стоит только один IP. В моём случае было 2. Удалил лишний перезапустил сетевое подключение - всё заработало.

      Удалить
    4. Рад, что смог помочь. :-)
      Вообще, это работает так:
      Клиент отправляет запрос на сервер DNS об имени хоста или IP. Если локальный DNS не может разрешить запрос - не располагает этими данными, он об этом отвечает и клиент отправляет запрос через default gw и, если следующий сервер DNS существует и достижим, то он обрабатывает этот запрос и отправляет ответ, в противном случае, не получив ответ в течение отведенного времени, клиент завершает запрос и, при пинге, выдается host unknown. Это все требует времени и довольно много, что видно "не вооруженным взглядом".
      В разнородных, мультидоменных средах, если по каким-то причинам нельзя или не надо реплицировать зоны DNS, можно использовать условную маршрутизацию с помощью форвардинга.
      На Вашем сервере можно поставить 2 DNS:
      1. 127.0.0.1
      2. ..0.2
      Это должно помочь. Можно, вместо 127..., поставить ..0.3, но лучше вариант 1 (правда он иногда не хочет нормально работать - фокусы показывает, но это не всегда).
      На клиентах тоже можно ставить 2 DNS и больше, но это всегда надо делать обдуманно ввиду того, что ответы кешируются и могут возникать некоторые проблемы. Эти проблемы решаются через ipconfig, но все же это уже может быть похоже на костыль. Форвард тут предпочтительней (IMHO).

      Удалить
  3. Это и есть ответ на мой вопрос: "Если локальный DNS не может разрешить запрос - не располагает этими данными, он об этом отвечает и клиент отправляет запрос через default gw и, если следующий сервер DNS существует и достижим, то он обрабатывает этот запрос и отправляет ответ"

    Я то думал, что за резолв имён отвечает ТОЛЬКО ДНС, и если он не может дать ответа, то на этом всё и заканчивается. А оказывается запрос передаётся на GW и тот ищет другой ДНС. Спасибо, это надо запомнить. К сожалению, такую информацию в явном виде нигде не нашёл.

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

      Удалить
    2. UPD: Важно так же понимать, что хост не будет стучаться куда ни попадя в поисках DNS - список серверов должен быть указан в сетевых настройках. Если в настройках указан 1 DNS и на нем не найдена подходящая запись, и не настроен форвард, то хост получит отлуп и на том дело закончится.

      Удалить
    3. То есть когда я указываю во вкладке "Forwarders" IP 10.0.0.2, я указываю не сам DNS-сервер (типа не нашёл на этом, смотри на этом и т.д.), а только шлюз, через который нужно искать следующий DNS. Правильно я понял?

      Удалить
    4. Ни в коем случае.
      В форвардах надо указывать адрес другого DNS-сервера и никак иначе. Достижимость же этого сервера необходимо определять правилами маршрутизации:
      что-нибудь типа: route add 10.X.Y.0 mask 255.255.255.0 10.0.0.2 metric 2
      и т. д.

      Удалить