Как включить днс сервер на ноутбуке. DNS сервер не отвечает

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

При этом для работы интернета требуется два типа серверов: основной и вспомогательный. Первый служит для размещения сайтов пользователей. В зависимости от того, какой объём информации отдаётся и получается, на сервере может храниться разное число сайтов - от одного (facebook.com, mail.ru, odnoklassniki.ru) до многих тысяч. Второй тип представлен вспомогательными серверами, которые помогают работать основной сети, обеспечивая общее взаимодействие. Одной из разновидностей таких вспомогательных устройств являются DNS-сервера.

Что собой представляет DNS-сервер и для чего используется

DNS-сервер является по сути компьютером, но не совсем. Он служит для размещения распределённой базы данных, входящей в систему доменных имён (DNS), которая используется для получения и передачи и передачи пользователям информации об интересующих доменах. DNS-сервера соединяются в сеть и взаимодействуют между собой по определённому протоколу.

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

Рассмотрим на практике всю последовательность. Браузер, в котором пользователь открывает сайт, изначально обращается к DNS-серверу и оповещает его, что хочет отыскать и попасть на сайт, адрес которого введён в текстовом поле адресной строки. Идём дальше. DNS-сервер определяет по своей базе, в каком месте сети находится сайт с таким именем, сопоставив его IP-адресу сервера с находящимся на нём ресурсом и отправляет туда запрос. В результате формируется ответ, состоящий из набора различных файлов, составляющих сам сайт (HTML-документы, изображения и таблицы, CSS-стили) и отправляется в браузер пользователя.

Где находятся настройки ДНС-сервера и как узнать его адрес в Windows 7

Рассмотрим ситуацию, когда пользователь на своём компьютере под управлением Windows 7 спокойно «путешествует» по интернету. Это значит, что DNS-сервер работает. Убедиться в этом можно, зайдя через вкладку «Администрирование» панели управления в меню «Службы» и посмотреть состояние DNS-клиента. Служба должна быть включена при выбранном автоматическом типе запуска.

Для того чтобы узнать адрес DNS-сервера, следует воспользоваться командой ipconfig/all, введя её в командной строке утилиты cmd.exe, запущенной от имени администратора.

Как установить и настроить: инструкция

DNS-сервер подключается при настройке сетевого протокола.

Последовательность запуска:

Выберите в нижней части рабочего стола (справа в трее) сетевое подключение, щёлкнув мышкой по соответствующей пиктограмме, и перейдите в открывшемся всплывающем окне по ссылке на вкладку управления сетевыми подключениями.
Выберите действующее подключение и в открывшемся окне нажмите кнопку «Свойства».
Выберите вкладку настройки свойств протокола интернета TCP/IPv4.
Отметьте радиокнопки автоматического получения адресов IP и DNS-сервера, нажмите «ОК» и закройте все открытые вкладки.

Следует заметить, что такая автоматическая настройка возможна только в том случае, если включена служба DHCP-клиент, обеспечивающая запуск и работу в сети DHCP-сервера. Её настройки можно посмотреть и изменить, выбрав соответствующий пункт в открытом окне системных служб вкладки «Администрирование» панели управления.

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

DNS-серверы Яндекс:

88.8.8;
88.8.1.

DNS-серверы Google:

8.8.8;
8.4.4.

DNS-серверы OpenDNS:

67.222.222;
67.220.220.

В зависимости от выбранной компании пара адресов вводится в окне свойств протокола интернета в поля предпочитаемого и альтернативного DNS-сервера при отмеченной радиокнопке их использования.

Возможные проблемы и пути их решения

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

Основные проблемы:

пропадает интернет и невозможно открыть ни одного сайта;
сайты в браузере не откраваются, но при этом торрент-клиент продолжает работать;
при попытке перезагрузки сетевого адаптера процесс «зависает»;
невозможно перезагрузить DNS-клиент, при этом выдаётся ошибка.

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

Видео: что делать, если DNS не отвечает, и как исправить другие неполадки

Сервер DHCP и его отличие от DNS

DHCP-сервер относится к вспомогательному типу серверов, содержащих сетевой протокол, обеспечивающий динамическую настройку узла на этапе автоматического конфигурирования любого сетевого устройства, подключаемого к интернету. Администратором сети при этом задаётся только диапазон адресов. В этом случае отсутствует ручная настройка и, соответственно, сокращается число возникающих ошибок. Так происходит потому, что сервер автоматически распределяет адреса между компьютерами в соответствии с заданным диапазоном. Большинство сетей TCP/IP работает по протоколу DHCP.

Как многим из вас, наверное, известно, DNS (англ.- Domain Name System - Система доменных имён) стала системой разрешения имён, используемой в Windows. Без неё компьютерам бы требовалось гораздо больше времени, чтобы соединиться друг с другом. Однако многие администраторы для преобразования имён в локальных сетях до сих пор применяют Windows Internet Name Service (WINS) и имеют мало (либо вообще не имеют) опыта работы с DNS. Если вы относитесь к данной категории, эта статья для вас. В ней рассказано, как установить, настроить и устранять неисправности в работе DNS-сервера на Windows Server 2008.

Установка DNS-сервера.

Установить DNS-сервер можно из Панели управления (Control Panel) или при преобразовании рядового сервера в контроллер домена, как показано на изображении A. Во время преобразования, система, не обнаружив DNS-сервер, предложит установить его.

Изображение A. Контроллер домена

Для установки DNS-сервера из Панели управления (Control Panel):

В меню Пуск (Start) выберите Панель управления (Control Panel)| Администрирование (Administrative Tools) | Управление сервером (Server Manager).
Раскройте вкладку и выберите объект Роли (Roles) (изображение B).
Нажмите Добавить роли (Add Roles) и следуйте указаниям мастера, выбрав в качестве роли сервера DNS-сервер (DNS-server) (изображение C).
Для того, чтобы установить DNS-сервер на ОС Windows Server 2008 нажмите Установить (Install) (изображение D).

Изображение B. Раскройте вкладку и выберите объект Роли (Roles)

Изображение C. Роль: DNS-сервер

Изображение D. Установка DNS

Консоль DNS и настройка

По завершению консоль управления DNS-сервером можно будет найти в меню Пуск (Start) | Программы (All Programs) | Администрирование (Administrative Tools) | DNS. В Windows 2008 встроен мастер настройки DNS-сервера
Для конфигурирования DNS-сервера понадобятся узнать значения следующих терминов:

1…Зона прямого просмотра (Forward lookup zone)
2…Зона обратного просмотра (Reverse lookup zone)
3…Типы зон (Zone types)

Зона прямого просмотра отвечает за преобразование имён хостов в IP-адреса. Зона обратного просмотра отвечает за распознавание DNS-сервером DNS-имени хоста, то есть, по сути, это антипод зоны прямого просмотра. Наличие зоны обратного просмотра не обязательно, но она легко настраивается и обеспечивает полную функциональность DNS в Windows Server 2008 Server.

При выборе типа зоны DNS даны следующие варианты: Active Directory (AD) Integrated (Интегрированная в AD), Standard Primary (Основная), и Standard Secondary (Дополнительная). Зона «AD Integrated» хранит информацию о распределённой базе данных в AD и позволяет осуществлять безопасное обновление файла базы данных. Эта опция доступна только при соответствующей настройке AD. Если выбрать её, AD будет хранить и тиражировать файлы зоны.

Основная зона (Standard Primary) хранит базу данных в текстовом файле, доступ к которому могут получить другие DNS-серверы, также хранящие информацию в текстовых файлах. Наконец дополнительная зона (Standard Secondary) создаёт копию существующей базы данных другого DNS-севера. Это нужно для выравнивания нагрузки.

Чтобы открыть мастера настройки DNS-сервера:

1…
2…Выделите имя вашего компьютера и нажмите Действие (Action) | Конфигурация DNS-сервера (Configure a DNS Server), чтобы запустить Мастера настройки DNS-сервера.
3…Нажмите Далее (Next) и выберите объект настройки: зона прямого просмотра (forward lookup zone), зоны прямого и обратного просмотра (forward and reverse lookup zone), только корневые ссылки (root hints only) (изображение E).
4…Нажмите Далее (Next) и потом Да (Yes) для того, чтобы создать зону прямого просмотра (изображение F).
5…Отметьте желаемый тип зоны (изображение G).
6…Нажмите Далее (Next) и введите имя создаваемой зоны.
7…Нажмите Далее (Next) и потом Да (Yes) для того, чтобы создать зону обратного просмотра.
8…Повторите шаг 5.
9…Выберите протокол зоны обратного просмотра: IPv4 или IPv6 (изображение H).
10… Нажмите Далее (Next) и ведите идентификатор зоны обратного просмотра (изображение I).
11…Можно создать новый или использовать копию уже существующего файла DNS (изображение J).
12…В окне Динамические обновления (Dynamic Update), выберите способ обновления DNS: безопасный (secure), небезопасный (nonsecure), неполучать динамических обновлений (no dynamic updates).
13…При желании можно включить перенаправляющий DNS-сервер в окне Перенаправление (Forwarders) (изображение K).
14…Нажмите Готово (Finish) (изображение L).

Изображение E. Настройка

Изображение F. Зона прямого просмотра

Изображение G. Желаемая зона

Изображение H. IPv4 или IPv6

Изображение I. Зона обратного просмотра

Изображение J. Новый или существующий файл DNS

Изображение K. Окно «Перенаправление»

Изображение L. Завершение

Управление записями DNS

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

Запись SOA (Start of Authority) - Начальная запись зоны
Запись NS (Name Server) - Сервер имён
Запись A (Host) - Запись узла
Запись PTR (Pointer) - Указатель
Запись CNAME (Canonical Name) или Alias - Каноническая запись имени (Псевдоним)
Запись MX (Mail Exchange) - Почтовый обменник

Начальная запись зоны (SOA)

Запись SOA является первичной в любой стандартной зоне. На вкладке Начальная запись зоны (Start of Authority) при необходимости можно произвести любые настройки, например, сменить первичный сервер, на котором хранится запись SOA или выбрать лицо, ответственное за управление SOA. И, наконец, главной особенностью Windows 2008 является возможность изменить конфигурацию DNS-сервера без его повторного создания и удаления зон (изображение M).

Изображение M. Изменение конфигурации

Серверы имён (name servers)

Записи Серверов имён (Name Servers) определяют имена серверов для конкретного домена. С их помощью устанавливаются все имена первичных и вторичных серверов.

Чтобы создать запись NS:

Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone).
Щёлкните правой кнопкой на требуемом домене и выберите пункт меню Свойства (Properties) (изображение N).
Перейдите на вкладку Серверы имён (Name Servers) и нажмите Добавить (Add).
Введите Имя FQDN-сервера (FQDN Server name) и IP-адрес (IP address) добавляемого DNS-сервера.

Изображение N. Сервер имён

А-запись

Запись A связывает имя хоста с IP-адресом. С их помощью серверы распознаются в зоне прямого просмотра, а выполнение запросов в средах с несколькими зонами происходит значительно лучше. Также можно создать запись указателя (PTR), которая связывает IP-адрес хоста с его именем.

Чтобы создать новый хост:

Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone) и щёлкните на папке, представляющей ваш домен.
Из меню Действие (Action) выберите команду Создать узел (New Host).
Введите имя и IP-адрес создаваемого узла (изображение O).
Отметьте параметр Создать соответствующую PTR-запись (Create Associated Pointer (PTR) Record), если параллельно хотите создать запись указателя (PTR). Либо вы можете создать её позже.
Нажмите кнопку Добавить узел (Add Host).

Изображение O. Запись A

Обратная запись (PTR).

Для выполнения обратных запросов указатели (PTR) создают соответствующие входящие сообщения в зоне обратного просмотра. Как видно на изображении H, при создании хоста можно также создать и запись PTR. Если вы не воспользовались этой опцией в тот момент, создать указатель можно будет в любое время.

Для создания записи PTR:

Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
Выберите зону обратного просмотра, где будет создан указатель.
Из меню Действие (Action) выберите команду Новый указатель (New Pointer) (изображение P).
Введите IP-адрес узла (Host IP Number) и Имя узла (Host Name).
Нажмите OK.

Изображение P. Новый указатель

Каноническое имя (CNAME) или псевдоним

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

Для создания псевдонима:

Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
Из меню Действие (Action) выберите команду Новый псевдоним (New Alias).
Введите каноническое имя (Alias Name) (изображение Q).
Введите полное имя домена (Fully qualified domain name, FQDN).
Нажмите OK.

Изображение Q. Каноническое имя

MX-запись

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

Для создания записи MX:

Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone) и выделите папку, представляющую ваш домен.
Из меню Действие (Action) выберите команду Создать почтовый обменник (New Mail Exchanger).
Введите имя Узла (Host) или Домена (Domain) (изображение R).
Введите Имя почтового сервера (Mail Server Name) и установите Приоритет почтового сервера (Mail Server Priority).
Нажмите OK.

Изображение R. Узел или домен

Другие новые записи

Вы можете создавать и другие виды записей. Для подробного описания в окне консоли DNS выберите из меню Действие (Action) команду Другие записи (Other New Records) (изображение S). Выберите любую запись и прочтите её описание.

Изображение S. Создание записей в консоли DNS

Устранение неполадок в работе DNS-серверов

Лучший помощник в устранении неисправностей DNS-серверов - утилита nslookup. Это гибкая и простая в применении утилита командной строки, входящая в состав Windows 2008. С её помощью можно протестировать запросы DNS-серверов, что помогает выявить причины проблем преобразования имён и других связанных с этим неполадок. Запустить nslookup (изображение T) можно прямо из консоли управления DNS.

Продолжая тему сайтостроения поговорим о таком важном аспекте, как работа системы доменных имен - 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 . Это позволяет администраторам зоны самостоятельно вносить необходимые изменения, не затрагивая при этом функционирования вышестоящей зоны и не обращаясь к ее администраторам по любому вопросу, требующему изменения записей.

Теги:

Please enable JavaScript to view the

Теперь пройдемся по основным настройкам DNS.

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

Идем в свойства данного сервера. Первая вкладка которая нас интересует это Интерфейсы. На ней перечислены интерфейсы которые должен слушать DNS сервер.

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

Вкладка дополнительно.

Позволяет включить автоматическое удаление старых записей

а так же задать откуда будет грузиться зона при старте

Вкладка наблюдение позволяет проверить правильность настройки DNS.

Якори доверия нужна для настройки DNSSEC цифровой подписи зоны

Теперь рассмотрим свойства конкретной зоны правый клик-свойства по нужной вам зоне. Первая будет вкладка Общие.

Можно задать обновление зоны, лучше оставить безопасное

Кнопка Очистка включаем удаление старых записей для данной зоны, цифры заданные тут суммируются с цифрой заданной в свойствах DNS сервера.

Начальная запись зоны (SOA)

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

Основной сервер - Сервер, отвечающий за данную зону

Ответственное лицо - тут можно прописать email ответственного.

Ну и про интервалы и так понятно все из названия.

Вернемся на вкладку общие и выберем пункт Интегрированный в AD Изменить

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

Если убрать галку то зона пересохранится в файл

Пункт Репликация Изменить позволит выбрать уровень реплики зоны.

Настройка репликации зон, интегрированных в Active Directory

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

Репликация и раздел каталога приложений

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

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

Каждый из этих разделов каталога приложений получает имя в соответствии с именем FQDN дочернего домена DNS. Эти разделы можно просмотреть в диспетчере DNS. Кроме того, каждая зона содержит имя DomainDnsZones, указывающее раздел, репликация которого выполняется лишь в локальных доменах.

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

Хранение данных DNS в разделе домена Данные зоны, интегрированной в Active Directory, хранятся в разделе домена вместе с остальными данными домена. В этой конфигурации репликация данных DNS выполняется не только на контроллерах домена, которые также являются DNS-серверами, но и па всех контроллерах локального домена. Однако при использовании этой опции генерируется дополнительный трафик репликации. Ее следует применять для репликации данных DNS на компьютерах Windows Server 2000.

Выбор области репликации зон

Раздел, в котором хранится зона, эффективно определяет область репликации для этой зоны, интегрированной в Active Directory. При использовании программы Dcpromo для назначения сервера контроллером нового домена в разделе DomainDnsZones автоматически создается новая зона, интегрированная в Active Direcrory. Однако при создании новой зоны с помощью мастера создания новой зоны на странице Область репликации зоны, интегрированной в Active Directory(Active Directory Zone Replication Scope), можно выбрать раздел для сохранения зоны.

На странице Область репликации зоны, интегрированной в Active Directory (ActiveDirectory Zone Replication Scope), представлены четыре опции.

■ Для всех DNS -серверов в этом лесу (То All DNS Servers In This Forest )

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

■ Для всех DNS серверов в этом домене (То All DNS Servers In This Domain )

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

■ Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain )

Зона сохраняется в разделе домена. Каждый контроллер локального домена получит копию этой зоны независимо от наличия па нем установленного DNS-сервера.

■ На все контроллеры домена , указанные в области данного раздела каталога (То All Domain Controllers Specified In The Scope Of This Directory Partition)

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

Область репликации созданной зоны можно изменить в любое время. Для этого на вкладке Общие (General) щелкните кнопку Изменить (Change) напротив параметра репликации.

Откроется диалоговое окно Изменение области видимости зоны репликации (Change Zone Replication Scope), в котором представлены те же опции выбора области репликации, что и на странице мастера создания новой зоны.

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

ПРИМЕЧАНИЕ: Повторное создание зон DomalnDnsZones и ForestDnsZones

Удаленные или поврежденные разделы каталога приложений можно воссоздать в диспетчере DNS, щелкнув правой кнопкой мыши узел сервера и применив команду Создать используемые по умолчанию разделы каталога приложений (Create Default Application Directory Partitions).

В следующих статья мы поговорим про nslookup dnscmd и раздел Каталога.