→ → Правильная настройка dns и сетевых интерфейсов!!! Что такое DNS и как ДНС-сервера обеспечивают работу интернета Установка днс сервера

Правильная настройка dns и сетевых интерфейсов!!! Что такое DNS и как ДНС-сервера обеспечивают работу интернета Установка днс сервера

При настройке модемов и роутеров перед пользователем может возникнуть необходимость указать такой параметр, как DNS-сервер. В этой статье расскажем, как подключить DNS сервер.

DNS - самостоятельная настройка

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

  1. Найдите в Панели управления раздел "Центр управления сетями и общим доступом".
  2. Укажите DNS-сервер в соответствующей ячейке. Обычно провайдер выдает два DNS-сервера, дабы при перегрузке первого система могла обратиться ко второму, в таком случае первый DNS указывается в ячейке "Предпочитаемый DNS-сервер", второй - в ячейке "Альтернативный DNS-сервер" (если вы не знаете, где посмотреть DNS, обратитесь к статье ).
  3. Нажмите "ОК".

DNS - получить автоматически

Можно также настроить получение DNS-серверов в автоматическом режиме:

  1. Зайдите в "Панель управления".
  2. Найдите в панели управления раздел "Центр управления сетями и общим доступом".
  3. Выберите используемую сеть - дважды кликните по сети левой кнопкой мыши.
  4. В новом окне нажмите на кнопку "Свойства".
  5. Кликните дважды левой кнопкой мыши по пункту "Протокол Интернет версии 4 (TCP/IPv4)".
  6. Отметьте точкой параметр "Получить адрес DNS-сервера автомаически".
  7. Нажмите "ОК".

Все! Система будет отыскивать подходящие параметры сети самостоятельно.

DNS - выбор

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

  • Google Public DNS , предпочитаемый - 8.8.8.8, альтернативный - 8.8.4.4;
  • Open DNS, предпочитаемый - 208.67.222.222, альтернативный - 208.67.220.220 или предпочитаемый - 208.67.222.220, альтернативный - 208.67.220.222.
  • Ultra DNS, предпочитаемый - 156.154.70.1, альтернативный - 156.154.71.1.
  • Яндекс DNS, предпочитаемый - 77.88.8.8, альтернативный - 77.88.8.1.
  • Яндекс DNS с фильтрацией опасных сайтов, предпочитаемый - 77.88.8.88, альтернативный - 77.88.8.2.
  • Яндекс DNS с фильтрацией сайтов для взрослых, предпочитаемый - 77.88.8.7, альтернативный - 77.88.8.3.

Дополнительно о настройке DNS читайте в статье

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

Описание ошибки

DNS (Domain Name System — система доменных имён) является мостом между восприятием человека и компьютера в том смысле, что позволяет преобразовать удобное для пользователя буквенное доменное имя (то, что пишется в адресной строке вида «www.google.com») в числовой эквивалент (IP-адрес узла), удобный для машины.

DNS ошибка (она же «Ошибка 105», ERR_NAME_NOT_RESOLVED) происходит, если веб-браузер не может провести преобразование, тогда доступ к сайту не будет получен.

Действия для устранения неисправности

В первую очередь необходимо выяснить, на каком уровне произошел сбой.

Возможные варианты с признаками:

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

Решение проблемы на уровне ПК

Первым делом убедитесь, что DNS служба работает и перезапустите её:


Не помогло? Следующий шаг - очистка кэша DNS .


Смена адреса DNS-сервера


Альтернативный DNS сервер

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

Обратите внимание на следующий момент: смена адреса DNS-сервера на один из лежащих в открытом доступе подвергает риску ваши данные. В целях безопасности пользуйтесь серверами с хорошей репутацией, например, Google Public DNS, OpenDNS, Яндекс.DNS.

Установка Google DNS

Войдите в «Сетевые подключения», выберете подключение к вашей сети, TCP/IPv4. Отметьте «Использовать следующие адреса DNS-серверов» и пропишите IP-адреса Google : 8.8.8.8 и 8.8.4.4.

Адреса других серверов прописываются аналогичным образом.

Особенности Google Public DNS

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

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

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

Неисправность антивируса

Неполадки с интернет-соединением может вызывать неисправный антивирус. Чтобы узнать, ваш ли это случай, переведите компьютер в безопасный режим.

Для Windows 10 переключение осуществляется следующим способом:


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

Проверка маршрутизатора

Неполадки на уровне Wi-Fi роутера по «симптомам» не отличаются от сбоя на уровне провайдера, но есть способ их отличить.

Отсоедините от роутера Ethernet-кабель и вставьте его в разъем компьютера.

Таким образом установится Ethernet-соединение. Если при подключении напрямую проблемы с интернетом устранились, дело в роутере, и его нужно перезагрузить.

Для перезагрузки выключите маршрутизатор, подождите 10-30 секунд и включите снова.

В остальных случаях

Если вы попробовали все вышеописанные методы, но устранить проблему не удалось (ни одна страница не загружается), обратитесь к своему провайдеру.

Если ошибку выдает один определенный сайт, причина сбоя на стороне его владельцев или хостинга. В таком случае придется ждать. Иногда информативным может быть поисковый запрос вида «почему сайт xxx.yyy.com не работает», который может пролить свет на источник проблем.

Заметили ошЫ бку

Выделите текст и нажмите Ctrl+Enter

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

Что такое доменное имя? Для многих это синоним адреса сайта, например, www.сайт . Набирая этот адрес вы твердо уверены, что попадете именно на этот сайт, а не куда-нибудь еще. В тоже время доменное имя может обозначать не только сайт, но и сервер электронной почты, обмена короткими сообщениями или иной другой интернет и сетевой сервис. Доменные имена входят в доменные зоны, которые расположены внутри друг друга в иерархическом порядке.

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

Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:

Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru , сom , org и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.

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

В свою очередь домены второго уровня тоже являются доменными зонами и позволяют размещать в себе домены третьего уровня, в которые, как в матрешку, помещать домены четвертого, пятого и т.д. уровней. Для того, чтобы можно было однозначно определять узлы, находящиеся в разных зонах, введено понятие полностью определенное имя домена (FQDN, Fully Qualified Domain Name ), которое включает в себя все имена родительских доменов в иерархии DNS. Например, для нашего сайта FQDN будет: сайт. Именно так, с окончанием на точку, обозначающее корневую зону.

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

Например, на нашем сервере в зоне сайт мы добавляем запись типа CNAME, которая будет указывать на сторонний сервер, скажем, Яндекс-почты. Правильно запись должна выглядеть так:

MailIN CNAMEdomain.mail.yandex.net.

В данном случае имя mail не является FQDN и будет дополнено до mail.сайт. , если же мы забудем поставить точку в конце имени домена Яндекса, то это имя также не будет восприниматься как FQDN и должно быть дополнено до полного имени домена. Ниже показана неправильная запись:

Mail IN CNAME domain.mail.yandex.net

Неподготовленным взглядом разницу заметить сложно, но вместо веб-интерфейса почты Яндекса такая конструкция отправит нас на несуществующий адрес: domain.mail.yandex.net.сайт.

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

Любая DNS-зона содержит записи только о входящих в нее узлах и дочерних зонах. Информация об узлах нижестоящей зоны хранится на ее собственных серверах. Это называется делегированием и позволяет снизить нагрузку на корневые сервера и предоставить необходимую автономию владельцам дочерних доменных зон.

Итак, вы купили домен, скажем, example.org , после чего вы должны его делегировать, т.е. указать сервера имен (DNS-сервера), которые будут содержать записи данной файловой зоны. Это могут быть как ваши собственные сервера, так и публичные сервисы, например, DNS Яндекса.

В этом случае в доменной зоне org будет добавлена запись:

Example IN NS dns1.yandex.net.

Которая будет указывать, что все записи этой зоны расположены на сервере dns1.yandex.net . По правилам, каждая доменная зона должна иметь не менее двух NS-серверов, расположенных в разных подсетях. На практике часто обходятся одним сервером, приобретая для него два IP-адреса из разных диапазонов.

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

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

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

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

Итак, клиент отправляет DNS-запрос серверу провайдера с целью узнать адрес домена market.yandex.ru , сервер провайдера не располагает подобной информации, поэтому обращается к одному из корневых серверов, передавая ему запрос. Корневой сервер также не имеет нужных записей, но отвечает, что знает сервер, отвечающий за зону ru - a.dns.ripn.net . Вместе с данным именем корневой сервер может сразу сообщить его IP-адрес (и в большинстве случаев сообщит), но может и не сделать этого, если не располагает такой информацией, в таком случае, перед тем как обратиться к данному серверу, нужно будет выполнить еще один рекурсивный запрос, только уже для определения его имени.

Выяснив адрес сервера, отвечающего за зону ru, сервер провайдера передаст запрос ему, но данный сервер также не имеет нужных записей, но сообщит, что за зону yandex отвечает сервер ns1.yandex.ru и обязательно сообщит его адрес. Иначе рекурсию завершить не удастся, так как за зону yandex отвечает сервер, находящийся в зоне yandex . Для этого в вышестоящей зоне, кроме NS-записи об обслуживающих зону серверах имен, создается "связанная" А-запись , которая позволяет узнать адрес такого сервера.

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

Теперь рассмотрим еще один момент. Запросы могут быть рекурсивными или нерекурсивными. Рекурсивный запрос предусматривает получение готового ответа, т.е. IP-адреса или сообщения что домен не существует, не делегирован и т.п. Нерекурсивный запрос предусматривает ответ только о той зоне, за которую отвечает данный сервер или возврат ошибки.

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

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

Например, если пользователь после посещения Яндекс Маркета решит воспользоваться почтовым сервисом, то сервер сразу направит запрос к ns1.yandex.ru , так как уже знает, какой сервер содержит записи для зоны yandex .

От теории к практике

Когда вы приобретаете у регистратора домен, вам будет предложено его делегировать, т.е. указать DNS-сервера, на которых будет расположена доменная зона. Это могут быть сервера регистратора (обычно бесплатно), сервера хостера, публичные DNS-сервисы или собственные сервера имен, если он будет расположен в этой же доменной зоне, то вам потребуется также указать IP-адреса. Например, так выглядит окно делегирования домена у одного известного регистратора:

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

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

1.2.3.4 example.com

Где 1.2.3.4 и example.com соответственно новый IP-адрес и имя вашего домена.

Если у вас свой VPS или вы хотите полностью контролировать доменную зону, то следует воспользоваться серверами регистратора или публичными сервисами. Создание собственного сервера имен, на наш взгляд, не оправдывающая себя затея, если только вы не делаете собственный хостинг.

В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:

@ IN A 1.2.3.4
www IN A 1.2.3.4

Символ "собачки" в DNS-записях обозначает сам домен, кроме того обязательно следует создать запись для поддомена www, чтобы пользователи, набравшие адрес сайта с www, также могли получить к нему доступ.

Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье:

При переносе сайта вам потребуется изменить только IP-адреса в A-записях и дождаться обновления DNS информации. Обычно, это самый неприятный момент - вроде бы все сделано, но ничего изменить вы не можете, остается только ждать. Но если выполнить некоторые рекомендации, то данный процесс можно провести максимально безболезненно и незаметно для посетителей.

Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:

Nslookup -typr=soa сайт

В нашем случае это 4 часа:

Поэтому заранее, не менее 4 часов (старое значение TTL) до планируемого переноса, измените значение TTL на более низкое, например, 900 (15 минут). Затем переведите свой сайт в режим "только чтение" и перенесите его на новый сервер. Выключать или переводить на техобслуживание сайт не следует, он может и должен оставаться доступным. Но вы должны исключить изменение и добавление информации пользователями, т.е. запретить регистрацию, комментирование, размещение заказов и т.п. Также не забудьте разместить на видном месте сообщение о технических работах и примерный срок их завершения.

Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.

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

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

У нас имеются публичные сервера для сайта и электронной почты и офисная сеть, для которой мы выделили поддомен office . Если с почтой и веб-сервером особых вопросов нет, то с офисной зоной есть варианты. Обычно локальная зона обслуживается собственным DNS и никак не связана с материнской зоной. Для глобальной системы DNS зона office.example.com не существует, но существует одноименный хост. Это оправдано, если сеть предприятия находится за NAT и ее узлы имеют только серые адреса, а доступ извне осуществляется только к шлюзу, на который проброшены соответствующие порты от внутренних узлов.

В этом случае DNS записи зоны example.com могут выглядеть следующим образом:

@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8

Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com , которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.

В локальной сети DNS-запросы клиентов обслуживает локальный сервер, которые имеет соответствующие записи, за ее пределами запросы будут направлены серверу, обслуживающему зону example.com . При этом все корпоративные ресурсы, которые в локальной сети представлены различными серверами, извне доступны по единственному адресу: office.example.com . Поэтому самое время вспомнить о записи псевдонима или CNAME. Данная запись позволяет связывать с реальным именем хоста дополнительные мнемонические имена или псевдонимы. При этом учтите, что использовать в других записях псевдонимов недопустимо. В нашем случае следует добавить записи:

Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.

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

Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.

Еще одно применение псевдонимов - это сокращение адреса. Допустим, в качестве почтового сервера для всего домена example.com мы хотим использовать сервер, который расположен в московском офисе и имеет адрес mail.office.msk.example.com , согласитесь, выглядит не слишком привлекательно. Гораздо удобнее был бы адрес вида mail.example.com , нет ничего проще, добавим следующую запись:

Mail IN CNAME mail.office.msk.example.com.

Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:

Example.com. IN MX 10 mail

Правильно будет так:

Example.com. IN MX 10 mail.office.msk

Напоследок поговорим о делегировании доменных зон. В примере выше мы рассмотрели ситуацию, когда внутри домена различным подразделениям выделены свои поддомены, так как у каждого подразделения имеется своя инфраструктура, то есть смысл делегировать им управление собственными доменными зонами. Для этого в зоне example.com следует разместить NS и связанную с ней A-запись для каждой зоны. Например:

Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.

ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Теперь при обращении по адресу, скажем mail.office.msk.example.com сервера имен зоны example.com будут выдавать имя и адрес сервера, обслуживающего зону msk.example.com . Это позволяет администраторам зоны самостоятельно вносить необходимые изменения, не затрагивая при этом функционирования вышестоящей зоны и не обращаясь к ее администраторам по любому вопросу, требующему изменения записей.

В последнее время часто встречаются вопросы, связанные с неправильной настройкой DNS (почта по IP -адресу работает, а по имени сервера — нет, и т.п.). В общем народ ленится, доки не читает, поэтому решил сделать краткую инструкцию по настройке DNS на компьютере с Kerio Winroute Firewall и клиентских компьютерах.

Рассматриваем три самых распространеных общих случая:

1. Одноранговая сеть, без домена (по определению тов. Naliman-а), точнее без DNS-сервера, в качестве шлюза в Интернет используется отдельная машина с установленным Winroute;
2. Сеть с доменом, DNS-сервер находится на DC (контроллере домена), в качестве шлюза в Интернет используется отдельная машина с установленным Winroute;
3. Сеть с доменом, DNS-сервер находится на DC, Winroute также установлен на этот DC.

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

Имеется в любом случае компьютер с двумя сетевыми картами (одна внутренняя — смотрит в локальную сеть, другая внешняя — в Интернет соответственно), играющий роль шлюза, через который мы и будем выходить в Интернет, и на который естественно 🙂 будет установлен Kerio Winroute Firewall.
Не забывайте, что адреса на этих сетевых картах должны быть из разных подсетей, т.е. например так:

192.168. 0 .1/24
192.168. 1 .1/24

почему-то новички очень часто на этом попадаются, если у них например ADSL-модем стоит.

1. Настройка DNS в одноранговой сети.

Настройки внутренней сетевой:

192.168.0.1 — IP-адрес компьютера с Winroute
255.255.255.0 — маска.
192.168.0.1 — в качестве DNS-сервера указываем IP-адрес этой же сетевой

ip 80.237.0.99 — реальный IP
mask 255.255.255.240 — маска
gate 80.237.0.97 — шлюз
dns 80.237.0.97 — DNS провайдера

Но! Не забиваем их втупую во внешнюю сетевую, а делаем немного по-своему:

ip 80.237.0.99
mask 255.255.255.240
gate 80.237.0.97
dns 192.168.0.1 — в качестве основного DNS-сервера указываем IP-адрес внутренней сетевой ;
80.237.0.97 — в качестве альтернативного DNS-сервера указываем DNS-сервер провайдера

Жмем Advanced . В закладке DNS убираем галочку на Register this connectionТs addresses in DNS, в закладке WINS убираем Enable LMHOSTS lookup и ставим Disable NetBIOS over TCP/IP. Также, галочек НЕ ДОЛЖНО БЫТЬ на Client for Microsoft Networks, Network Load Balancing, Fail and Printer Sharing Microsoft Networks.

Кстати, удобно переименовать внешний интерфейс, назвать не Local Area Connection (Подключение по локальной сети), а например Internet Interface.

Дальше, заходим в Панель управления, Cетевые подключения, в этом окне (окно проводника) меню Дополнительно -> Дополнительные параметры. Во вкладке «Адаптеры и привязки» передвигаем «Local Area Connection» («Подключение по локальной сети») на самую верхнюю позицию:

На клиентском компьютере настройки сетевой карты будут примерно такие:

ip 192.168.0.2
mask 255.255.255.0
gate 192.168.0.1 —
dns 192.168.0.1 — в качестве основного DNS-сервера указываем IP-адрес компьютера с Winroute

В Winroute, Configuration -> DNS Forwarder ставим галку «Enable DNS Forwarding», указываем DNS-серверы провайдера.

2. Сеть с доменом, DNS-сервер находится на DC (контроллере домена), в качестве шлюза в Интернет используется отдельная машина с установленным Winroute

Настройки не очень отличаются от предыдущего варианта, в принципе все тоже самое, только:

2.1 В зонах прямого просмотра DNS следует убрать зону «.», если она там есть. После этого перезапустить службу «DNS-сервер».

2.2 На контроллере домена в свойствах DNS нужно разрешить пересылку на IP-адрес DNS-сервера провайдера, в данном случае 80.237.0.97 (и не забыть добавить правило в Traffic Policy, разрешающее контроллеру обращаться на DNS-сервер провайдера):

2.3 DNS Forwarder в Winroute выключаем (убираем галку «Enable DNS Forwarding»), так как он у нас есть уже в на нашем DNS-сервере.

2.4 На контроллере домена в DNS необходимо создать зону обратного просмотра (у правильных админов она наверняка создана еще при поднятии DNS 🙂), так как без нее невозможно по IP-адресу определить имя компьютера. В качестве кода сети указываем первые 3 группы цифр своего IP-адреса.
Для проверки заходим в свойства зоны и убеждаемся там в наличии нашего DNS-сервера (или серверов, если их несколько) на закладке «Серверы имен». Если серверов не хватает, добавляем их туда. Желательно делать это с помощью «Обзора». Все. Осталось разрешить динамическое обновление, чтобы клиентские машины регистрировались в этой зоне, хотя можно обойтись и без этого.

2.5 Настройки внутренней сетевой компьютера с Winroute:

ip 192.168.0.1 — IP-адрес компьютера с Winroute
mask 255.255.255.0 — маска
dns 192.168.0.100 —

Шлюз НЕ указываем!

Настройки внешней сетевой:

ip 80.237.0.99
mask 255.255.255.240
gate 80.237.0.97 — в качестве шлюза указываем IP-адрес шлюза, данный провайдером
dns 192.168.0.100 — в качестве основного DNS-сервера указываем IP-адрес локального DNS-сервера (DC)

Альтернативный DNS-сервер не указываем! Он у нас имеется в пересылке.

2.6 Настройки клиента:

ip 192.168.0.2
mask 255.255.255.0
gate 192.168.0.1 — в качестве шлюза указываем IP-адрес компьютера с Winroute
dns 192.168.0.100 — в качестве основного DNS-сервера указываем IP-адрес локального DNS-сервера (DC)

2.7 Для проверки на клиенте следует выполнить команды:

nslookup {GateWayName}
nslookup {GateWayIP}
nslookup yandex.ru
nslookup 213.180.204.11

Если в результате выполнения всех вышеперечисленных команд нет сообщений об ошибках — значит все у вас получилось.

Исправления и дополнения принимаются.

Проблема перманентной недоступности серверов DNS (Англ.Domain Name System - система доменных имён), к сожалению, продолжает упорно существовать в белорусском сегменте всемирной паутины.

Как себя проявляет на компьютере или ноутбуке сбой службы DNS

В системном трее (область уведомлений возле часов): значок сети с восклицательным знаком. При этом деньги на балансе провайдера есть; компьютер (ноутбук) работает нормально.

Такая проблема встречается в том числе на популярном ADSL модеме HUAWEI HG532e. Иногда данный девайс начинает корректно работать только после его перезапуска.

При запуске команды ping посредством интерпретатора командной строки: виден лишь мигающий курсор.

Этапы устранения неполадки с DNS

Для устранения проблемы с DNS:

  1. проверяем запущена ли служба DNS-клиент на компьютере;
  2. переходим на публичные DNS от Google.

Проверяем работоспособность службы DNS в системе Windows

На компьютере нажимаем WIN+R ( Windows- значок на клавиатуре).

В появившемся окошке набираем команду services.msc. Появится полный список служб, находим DNS-клиент. Проверяем тип запуска – Автоматический, Состояние – работает. ОК. Если так и есть идём дальше….нет? Исправляем.

Далее переходим на публичные DNS от Google

В закладке Использовать следующие адреса DNS-серверов вводим значения:

  • в первое поле (предпочитаемый DNS-сервер) – 8.8.8.8
  • во второе (альтернативный DNS-сервер) – 8.8.4.4

Жмём ОК и закрываем. Сейчас наш компьютер настроен на получение DNS адресов сервиса Google Public DNS. В некоторых случаях DNS сервер лучше настраивать сразу в интерфейсе роутера, как например в случае с .

На этом ручная настройка компьютера на работу с Google Public DNS закончена.

Как правило, настройки сетевой карты компьютера для работы через публичные сервера Google достаточно для устранения проблемы с ошибкой “DNS-сервер не отвечает”.

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

Существует возможность сделать автоматическую настройку DNS с помощью специального ПО. Достаточно интересна в этом плане программа .

Она умеет изменять настройки DNS нажатием одной кнопки. Функционал позволяет также и рекомендовать самый быстрый.

 

 
Это интересно: