Настройка зоны прямого просмотра dns
В своё время открыл для себя простую истину: хочешь запомнить что-то — веди конспект (даже при чтении книги), а хочешь закрепить и систематизировать — донеси до людей (напиши статью). Поэтому, после двух лет работы в системной интеграции (сфере, которую я в бытность свою системным администратором, считал просто рогом изобилия для жаждущих прокачки специалистов), когда я понял, что знания постепенно вытесняются навыками правки документации и конфигурированию по мануалам и инструкциям, для поддержания формы я начал писать статьи о базовых вещах. Например вот — о DNS. Делал тогда я это больше для себя, но подумал — вдруг кому пригодится.
Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.
Содержание:
(анкеров нет, поэтому содержание без ссылок)
1. Основные сведения
DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:
А — то самое сопоставление символьного имени домена его IP адресу.
АААА — то же что А, но для адресов IPv6.
CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.
MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.
NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.
SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.
SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.
Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.
Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):
Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.
Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.
Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.
В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.
В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.
Итеративный и рекурсивный запросы.
DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.
Клиент обращается к держателю зоны ru с тем же запросом.
DNS яндекса возвращает нужный адрес.
Такая последовательность событий редко встречается в наше время. Потому что есть такое понятие, как рекурсивный запрос — это когда DNS-сервер, к которому клиент изначально обратился, выполняет все итерации от имени клиента и потом возвращает клиенту уже готовый ответ, а также сохраняет у себя в кэше полученную информацию. Поддержку рекурсивных запросов можно отключить на сервере, но большинство серверов её поддерживают.
Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».
Заголовок состоит из следующих полей:
Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.
Флаги — 16-битовое поле, поделенное на 8 частей:
Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.
3. TCP и UDP
Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.
4. DNS в Windows Server 2008 и 2012
В Windows 2008 появились следующие возможности:
Фоновая загрузка зон
- определяются все зоны, которые должны быть загружены;
- из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
- загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
- начинается обработка запросов и удаленных вызовов процедур (RPC);
- создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.
Поскольку задача загрузки зон выполняется отдельными потоками, DNS-сервер может обрабатывать запросы во время загрузки зоны. Если DNS-клиент запрашивает данные для узла в зоне, который уже загружен, DNS-сервер отправляет в ответ данные (или, если это уместно, отрицательный ответ). Если запрос выполняется для узла, который еще не загружен в память, DNS-сервер считывает данные узла из доменных служб Active Directory и обновляет соответствующим образом список записей узла.
Поддержка IPv6-адресов
Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.
Изменения DNS-клиента
Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.
Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.
5. DNS и Active directory
Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.
Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.
SRV записи регистрируемые службой Net Logon:
_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:
_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;
_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
_kpassword — идентифицирует серверы изменения паролей kerberos в сети;
_gc — запись, относящаяся к функции глобального каталога в Active Directory.
В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.
Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.
DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.
Как происходит процесс поиска DC
Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.
Служба посылает один или несколько запросов с помощью API функции DsGetDcName()
DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.
Все доступные контроллеры доменов отвечают на этот запрос, сообщая о своей работоспособности.
После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.
Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).
Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.
Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)
DNS (Domain Name System, Система Доменных имен) – система, позволяющая преобразовать доменное имя в IP-адрес сервера и наоборот.
DNS-сервер – это сетевая служба, которая обеспечивает и поддерживает работу DNS. Служба DNS-сервера не требовательна к ресурсам машины. Если не подразумевается настройка иных ролей и служб на целевой машине, то минимальной конфигурации будет вполне достаточно.
Создание зоны прямого просмотра на DNS сервере 2012 R2
На группе «Зоны прямого просмотра» щелкаем правой кнопкой мыши и выбираем «Создать новую зону»
После у нас запустится мастер создания новой зоны, жмем «Далее»
В следующем окне выбираем тип наше зоны, описание можете посмотреть непосредственно под каждым типов, я выбираю «Основную» жму «Далее»
Затем нам предстоит написать имя нашей зоны, в моем случае, так как сервер тестовый я выберу имя local, Вы в свою очередь пишете, название вашего домена, или если Ваш домен не будет иметь выхода в Интернет другими словами локальный (чисто в Вашей сети), то в принципе можете писать все что угодно.
Далее я выбираю «Создать новый файл», так как у меня другого DNS сервера нет, жму «Далее»
Затем предстоит выбрать «Тип динамического обновления» я пока такой функционал запрещу, но в последствии я всегда могу его включить, а Вы можете включить его, если, например, у Вас DNS сервер только для Вашей локальной сети, жму «Далее»
Заключительное окно, которое говорит нам, что все готово, мы соответственно и жмем «Готово»
Вот и все зона создана, давайте создадим запись типа A, например для нашего же сервера. Для этого по зоне щелкаем правой кнопкой мыши и жмем «Создать узел A или AAAA»
Затем вводим имя нашего узла, которое мы хотим, чтобы у него было, и соответственно какой у него IP адрес, это уже по факту. Жмем «Добавить узел»
И появится соответствующая запись
Затем не забываем проверить, какой днс сервер установлен у нас в настройках сетевого интерфейса (он должен быть соответственно наш, т.е. ip адрес этого сервера). Потом соответственно мы можем проверить работу только что установленного DNS сервера, например, запустить командную строку и попробовать пропинговать узел который мы создали чуть ранее
Как видите, система распознала по доменному имени его IP адрес. И на этом предлагаю заканчивать. Удачи!
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
- Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
- Резолверпосылает запрос указанному серверу имен.
- Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
- Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
- Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
- пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
- и «вложенности» доменных имен.
- В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
- Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
- Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
- Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
- Запись заголовка — служебную информацию о запросе.
- Запись запроса — повторяет отправленный запрос.
- Запись ответа — собственно, сам ответ.
- Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
- Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Наглядно приведенную схему можно представить командами:
Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Резюме
Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.
Что еще почитать:
Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.
DNS (Domain Name System) – система доменных имен. В статье Настройка простой (одноранговой) локальной сети мы задавали IP адреса компьютеров и использовали их для удаленного подключения. Если простейшая сеть состоит (минимум) из двух компьютеров, то нет проблем, все ОК и хорошо.
Но, представим, что наша сеть разрослась до сотни, тысячи десятков тысяч и более компьютеров. Суть DNS в том, что DNS хранит данные о соответствии IP-адреса домену. То есть каждому IP-адресу, состоящему из цифр, соответствует буквенное имя, домен (Domain).
Благодаря DNS в компьютере хранится таблица соответствия вида «Имя домена» = «IP-адрес».
Так же система доменных имен удобнее визуально, согласитесь проще запомнить имя mycomp чем IP-адрес 192.168.1.1 , особенно если таких компьютеров много. Например, компьютер бухгалтера можно назвать compbuh и не запоминать его IP-адрес.
Соответствия IP-адресов именам, ресурсные записи доменов, а так же иную информацию хранит в себе DNS-сервер. По сути своей DNS-сервер это служба которая обеспечивает работоспособность DNS.
DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) – это сетевой протокол, который позволяет получать устройствам, например компьютерам, IP-адреса автоматически.
Например, у вас дома стоит роутер, который раздает интернет. У вас есть компьютер и ноутбук. Именно DHCP раздает вашим устройствам (компьютеры, ноутбуку, смартфону) IP-адреса. Именно IP-адреса позволяют устройствам обмениваться информацией с роутером, благодаря чему на устройствах есть интернет.
Рассмотрим установку DNS на Windows Server 2012.
Установка роли DNS-сервера
Для установки дополнительных ролей на сервер используется Мастер Добавления Ролей и Компонентов, который можно найти в Диспетчере Сервера.
- В левой части окна Диспетчера сервера откройте раздел Роли, после чего в правой части окна отобразится команда Добавить Роли:
- Откроется окно Мастера, в котором рекомендуют убедиться что:
1. Учётная запись администратора защищена надёжным паролем.
2. Настроены сетевые параметры, такие как статические IP-адреса.
3. Установлены новейшие обновления безопасности из центра обновления Windows.
- Убедившись, что все условия выполнены, нажмите Далее;
- Отметьте чек-боксом роль DNS-сервер и перейдите Далее:
- Убедитесь, что выбор сделан правильно, и подтвердите нажатием кнопки Установить:
- Дождитесь завершения установки и закройте Мастер установки:
Настройка сетевого адаптера для DNS-сервера
Установка DNS-сервера предполагает наличие доменной зоны, поэтому необходимо создать частную сеть в личном кабинете и подключить к ней виртуальные машины.
После того, как машина будет присоединена к двум сетям, важно не перепутать, какое из подключений требует настройки. Первичный сетевой адаптер настроен автоматически с самого начала, через него открыт доступ к интернету, в то время как на дополнительно подключенных сетевых адаптерах доступа в интернет нет, пока не будет произведена ручная настройка:
Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.
Далее предстоит проделать цепочку действий:
- Необходимо нажать правой клавишей мыши по значку сети в системном трее, в выпадающем меню выбрать Центр управления сетями и общим доступом, в левой части появившегося окна открыть ссылку Изменение параметров адаптера:
- Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
- В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
- Заполнить соответствующие поля необходимыми данными:
Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].
Что такое DNS и DNS сервер?
DNS (Domain Name System) – это система доменных имён, которая позволяет по доменному имени узнать IP адрес хоста и наоборот. Так как у каждого компьютера или сетевого устройства есть свой IP адрес и для того чтобы обратиться к тому или иному компьютеру или устройству соответственно нужно знать этот IP адрес, но так как запоминать определенную последовательность цифр не удобно, да и как если, например Вы обращаетесь ко многим компьютерам (запомнить просто не реально) поэтому чтобы не запоминать эти цифры, и существует система доменных имен, например, что лучше для восприятия 192.168.1.1 или mycomp. Вот такое простое определение, но так как материал для начинающих администраторов, этого вполне достаточно.
Хватит теории, и так как материал посвящен именно установки роли DNS сервер, давайте переходить непосредственно к этому.
Примечание! Как видно из названия, DNS сервер мы будем устанавливать на ОС Windows Server 2012 R2 Datacenter, только мы будем использовать, как и в прошлых статьях, ознакомительную версию.
Шаг 7
На следующем окне нам говорят, на что обратить внимание при установке роли DNS сервер, жмем «Далее»
Создание зоны прямого просмотра на DNS сервере
В диспетчере DNS на группе «Зоны прямого просмотра» необходимо щелкните правой кнопкой мыши и выберите «Создать новую зону». Запустится мастер создания новой зоны. Нажмите «Далее».
Выберите «Создать новый файл», так как другого DNS сервера нет, нажмите «Далее».
Затем нужно выбрать «Тип динамического обновления» на время такой функционал стоит запретить. Жмем «Далее» и «Готово».
Зона создана, теперь можно сделать запись типа A, например, для этого же сервера. Для этого по зоне нужно щелкнуть правой кнопкой мыши и нажать «Создать узел A или AAAA».
Далее отключаем брандмауэр Windows Server: Центр управления сетями и общим доступом -> Брандмауэр Windows (слева внизу) -> Включение и отключение брандмауэра Windows — > отключаем для всех типов сетей.
Далее задаем IP-адрес сервера. Проверяем созданную зону.
Проверить работу только что установленного DNS сервера, например, запустить командную строку и попробовать пропинговать узел который был создан чуть ранее.
Обучаю HTML, CSS, PHP. Создаю и продвигаю сайты, скрипты и программы. Занимаюсь информационной безопасностью. Рассмотрю различные виды сотрудничества.
Установка DNS сервера на Windows Server 2012 R2
Шаг 4
Затем предстоит выбрать сервер, на который будет производиться установка роли DNS сервера, так как у меня сервер один я его и выбираю, жму «Далее»
Шаг 8
Все подтверждаем установку нажатием кнопку «Установить», ставить галочку «Автоматический перезапуск сервера» в данном случае не нужно.
Вот и все началась установка
Все, роль сервера DNS-сервер установлена. Для запуска средств управления DNS сервером используйте Диспетчер серверов->Средства ->DNS
Или через меню Пуск
Само средство управления выглядит следующим образом
Шаг 1
Открываем диспетчер серверов и выбираем «Добавить роли и компоненты»
Установка DNS на Windows Server 2012
Откройте диспетчер серверов и выберите пункт «Добавить роли и компоненты».
На следующей странице установите флажок «Пропускать эту страницу по умолчанию» и нажмите «Далее».
В окне «Выбор типа установки» нажмите «Далее».
Выберите сервер, на который будет производиться установка роли DNS сервера. Если у вас один сервер, выбираете его. Если несколько — необходимый. В моем примере один сервер.
Далее нужно выбрать, какие роли необходимо устанавливать, соответственно нужно установить роль DNS сервера, поэтому выбирается он. Нажимаем «Далее».
Выбор компонентов уже осуществлен, нажимаем «Далее».
Далее появляется информация, на что обратить внимание при установке роли DNS сервера, нужно нажать «Далее».
Далее необходимо подтвердить установку нажатием кнопки «Установить».
После чего запускается процесс установки, который длится около 3 минут.
Дождитесь завершения установки и нажмите кнопку «Закрыть».
Роль сервера DNS-сервер установлена. Для запуска средств управления DNS сервером нужно использовать Диспетчер серверов -> Средства -> DNS.
Шаг 2
На следующем окне ничего не нужно делать, это окно простое напоминание администратору о том, что учетная запись администратора должна быть защищена надежным паролем, о том, что необходимо устанавливать все последние обновления, кстати, можно сделать так чтобы это окно не появлялось в следующий раз, для этого поставьте соответствующую галочку. И жмем «Далее»
Создание зон прямого и обратного просмотра
Доменная зона — совокупность доменных имён в пределах конкретного домена.
Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.
Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.
Создание зон и управление ими осуществляется при помощи Диспетчера DNS.
Данный инструмент открывается из навигационного дерева Диспетчера Сервера:
Создание зоны прямого просмотра
- Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:
- Откроется окно Мастера с приветствием, нажмите Далее:
- Из предложенных вариантов выберите «Основная зона» и перейдите Далее:
- При необходимости поменяйте название будущего файла зоны и нажмите Далее:
- Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:
- Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:
Создание зоны обратного просмотра
- Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер создания новой зоны:
- Выберите назначение для адресов IPv4, нажмите Далее:
- Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:
- При необходимости поменяйте название будущего файла зоны и перейдите Далее:
- Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:
- Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:
Создание A-записи
Данный раздел инструкции в большей степени предназначен для проверки ранее проделанных шагов.
Ресурсная запись — единица хранения и передачи информации в DNS, заключает в себе сведения о соответствии какого-либо имени с определёнными служебными данными.
Запись A — запись позволяющая по доменному имени узнать IP-адрес.
Запись PTR — запись обратная A записи.
- В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду "Создать узел (A или AAAA). ":
- Откроется окно создания Нового узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс «Создать соответствующую PTR-запись» — чтобы проверить работу обеих зон (прямой и обратной), чекбокс должен быть активирован:
Если поле имени остается пустым, указанный адрес будет связан с именем доменной зоны.
- Также можно добавить записи для других серверов:
Проверка
- Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):
- Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:
- Запрос по домену;
- Запрос по IP-адресу:
В примере получены подходящие ответы по обоим запросам.
В дополнение к имени домена и адресам появилась строчка «Non-authoritative answer:», это значит, что наш DNS-сервер не обладает необходимой полнотой информации по запрашиваемой зоне, а информация выведенная ниже, хоть и получена от авторитетного сервера, но сама в таком случае не является авторитетной.
Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:
Здесь машина сама себе назначена предпочитаемым DNS-сервером. Доменное имя DNS-сервера отображается как неопознанное, поскольку нигде нет ресурсных записей для IP-адреса (10.0.1.7). По этой же причине запрос 2 возвращает ошибку (Non-existent domain).
Сейчас мы установим роль сервера DNS-сервер на операционной системе Microsoft Windows Server 2012 R2 Datacenter, затем создадим зону прямого просмотра, а также вспомним, что такое вообще DNS и для чего он нужен.
И прежде чем устанавливать и настраивать DNS сервер, давайте вспомним, что такое DNS и DNS сервер. Так как подобной информации в Интернете полно мы рассмотрим это кратко и перейдем сразу к делу. Напомню, что в прошлых статьях мы рассматривали установку Windows Server 2012 R2 и установка и настройку DHCP сервера на этой же операционной системе, теперь продолжаем и на очереди у нас DNS сервер.
Шаг 5
Вот как раз на этом шаге и нужно выбрать, какие роли мы будем устанавливать, а мы соответственно будем устанавливать роль DNS сервер, поэтому выбираем его
Затем нам сразу предложат установить средства администрирования DNS сервера, и так как я буду администрировать его на этом же сервере, я жму «Добавить компоненты», чтобы на следующем шаге их не искать и принудительно не выбирать. А если Вы будете администрировать DNS сервер с другого сервера, то можете и не добавлять эти средства, а добавить их соответственно на том сервере, с которого будет осуществляться настройка и управление.
Затем жмем «Далее»
Настройка сетевого адаптера для DNS-сервера
Установка DNS-сервера предполагает наличие доменной зоны, поэтому необходимо создать частную сеть в личном кабинете и подключить к ней виртуальные машины.
После того, как машина будет присоединена к двум сетям, важно не перепутать, какое из подключений требует настройки. Первичный сетевой адаптер настроен автоматически с самого начала, через него открыт доступ к интернету, в то время как на дополнительно подключенных сетевых адаптерах доступа в интернет нет, пока не будет произведена ручная настройка:
Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.
Далее предстоит проделать цепочку действий:
- Необходимо нажать правой клавишей мыши по значку сети в системном трее, в выпадающем меню выбрать Центр управления сетями и общим доступом, в левой части появившегося окна открыть ссылку Изменение параметров адаптера:
- Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
- В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
- Заполнить соответствующие поля необходимыми данными:
Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].
Шаг 3
На этом шаге, также ничего не нужно делать, все по умолчанию выбрано правильно именно так как нам и нужно, жмем «Далее»
Шаг 6
И так как компоненты мы уже добавили нам искать их здесь не нужно, но для примера я покажу, где они находятся и что они уже выбраны, жмем «Далее»
Читайте также: