В организации DNS нужно конфигурировать не только на отдельном сервере, но и для всей сети. DNS-серверы следует размешать таким образом, чтобы можно было управлять рабочей нагрузкой при обработке данных серверами, снизить объем трафика между серверами и клиентами и сократить время реагирования DNS-серверов на запросы клиентом. Во всех организациях, кроме самых мелких, для выполнения таких задач нужно развернуть больше одного DNS-сервера.
При развёртывании нескольких DNS-серверов в организации согласованность данных на таких серверах становится важным аспектом конфигурирования и управления DNS в сети. Чтобы DNS-серверы в организации обеспечивали синхронизированную текущую информацию для клиентов, нужно отконфигурировать репликацию и передачу зон.
Репликация зон — это процесс синхронизации данных зон, интегрированных в Active Directory. Передача зон — это синхронизация данных зон междуглавной и дополнительной стандартной зоной. Эти два механизма основаны наразных технологиях, поэтому настраиваются отдельно.
Настройка репликации зон, интегрированных в 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 (Active Directory 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 ).
Создание настраиваемого раздела каталога приложения
Вы можете создавать собственные настраиваемые разделы каталога приложения для использования DNS , а затем перечислить выбранные контроллеры доменов в сети для управления репликами этого раздела. Для выполнения этой задачи сначала создайте раздел с помощью такойкоманды:
dnscmd имя_сервера /createdirectorypartition hmp_FQDN
Затем перечислите в разделе другие DNS -серверы с помощью следующей команды:
dnscmd имя_сервера / enlistdirectorypartition имя_ FQDN
Так, чтобы создать раздел каталога приложений DNSpartitionA на компьютере Server 1 в домене Active Directory с именем microsoft . com , введите такую команду:
dnscmd server1 /createdirectorypartition DNSpartitionA.microsoft.com
ПРИМЕЧАНИЕ: Использование точки (.) для указания имени локального сервера
Если команда выполняется на том же сервере, где был создан раздел, вместо имени локального сервера можно использовать точку.
Чтобы перечислить в разделе каталога приложений компьютер Server 2, введите такую команду:
dnscmd server2 /enlistdirectorypartition DNSpartitionA.microsoft.com
ПРИМЕЧАНИЕ: Кто может создавать раздел каталога приложений
Раздел каталога приложений может создать лишь член группы Администраторы предприятия (Enterprise Admins ).
Созданный раздел каталога приложений появится в раскрывающемсясписке на странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope ) мастера создания новой зоны и вдиалоговом окне Изменение области видимости зоны репликации (Change Zone Replication Scope ). Чтобы сохранить зону в новом разделе, выберите опцию На все контроллеры домена, указанные в области данного раздела каталога (То А ll Domain Controllers Specified In The Scope Of This Directory Partition ), и враскрывающемся списке укажите этот раздел.
Передача зон
Если все DNS -серверы расположены на контроллерах доменов, для обеспечения согласованности данных зон среди всех DNS -серверов используется репликация Active Directory . Однако эта возможность недоступна при установке DNS -сервера на компьютере, не являющемся контроллером домена. В таком случае зону нельзя сохранять в Active Directory , вместо этого нужно использоватьстандартную зону, которая сохраняет данные в локальном текстовом файле на каждом DNS -сервере. Если в организации используется много DNS -серверов, тоисходные данные можно копировать в управляемые другими серверамидополнительные зоны с правом только для чтения. Для того чтобы обеспечитьсогласованность и обновление данных между основной и дополнительными зонами, нужно настроить передачу зон.
Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны,интегрированной в Active Directory . К примеру, у вас есть два сайта - один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежитотдельному домену Active Directory . В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.
Включение передачи зон
Передача данных для дополнительных зон может быть инициирована в любом из трех случаев.
■ По истечении интервала обновления начальной записи SOA основной зоны.
■ При загрузке дополнительной зоны сервером.
■ В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях.
По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers ) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.
■ На любой сервер (To Any Server ) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следуетиспользовать только в частных сетях с высоким уровнем безопасности.
■ Только на серверы, перечисленные на странице серверов зон (Only To Servers Listed On The Name Servers Tab ) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.
■ Только на серверы из этого списка (Only To The Following Servers ) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.
Настройка уведомлений
На вкладке Передача зон (Zone Transfers) можно также настроить уведомление, которое будет отправлено дополнительным серверам в случае изменений в основной зоне. Поскольку передача зон представляет собой операции PULL, их нельзя конфигурировать для переноса новых данных на дополнительныесерверы. Вместо этого при модификации данных основная зона отправляетуведомление на все указанные серверы, управляющие дополнительными зонами. Дополнительная зона, получившая уведомление, инициирует передачу зоны.
Для настройки уведомлений на вкладке Передача зон (Zone Transfers ) щелкните кнопку Уведомить (Notify ). Откроется диалоговое окно Уведомление(Notify ), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.
контекстное меню, в котором можно использовать следующие операции дляобновления зоны.Перезагружается дополнительная зона из локального хранилища.
■ Передать зону с основного сервера (Transfer From Master)
Сервер, управляющий локальной дополнительной зоной, определяет истечение интервала обновления серийного номера дополнительной зоны в записи SOA и выполняет передачу зоны с главного сервера.
■ Перезагрузить повторно зону с основного сервера (Reload From Master)
Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.
Использование зон-заглушек
Зона-заглушка — это копия, которая содержит лишь основные записи главной зоны. Назначают зону-заглушку, чтобы локальный DNS-сервер мог пересылать запросы на уполномоченные серверы имен в главной зоне. Таким образом, зона-заглушка функционально идентична делегированию зон. Тем не менее,поскольку зоны-заглушки могут инициировать и принимать передачу зон из главной (делегированной) зоны, они обеспечивают дополнительное информирование родительских зон об обновлениях в записях NS дочерних зон.
Зоны-заглушки можно использовать в следующих целях:
■ Обновление данных делегированной зоны
Регулярно обновляя зону заглушку для одной из своих дочерних зон, DNS-сервер, управляющий родительской зоной и зоной-заглушкой, будет поддерживать текущий список полномочных DNS-серверов для дочерней зоны. Делегированная зона — это дочерняя зона родительской зоны, управление которой осуществляется па собственном DNS-сервере. В случае делегирования родительская зонасодержит запись NS для сервера, управляющего этой дочерней зоной. Таким образом, при получении запросов имен в дочерней зоне родительская перенаправляет их па сервер, указанный в записи NS.
Пример зоны-заглушки
Предположим, вы работаете администратором DNS -сервера Dns 1. microsoft . com , который уполномочен для зоны Microsoft . com . Ваша компания имеет дочерний домен Active Directory с именем India . microsoft . com , для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная и Active Directory , содержит только два полномочных DNS -сервера - 192.168.2.1 и 192.168.2.2. Позже администраторы домена India . microsoft . com развертывают дополнительные контроллеры домена и устанавливают роль DNS -сервер (DNS Server ) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS -серверы на свой домен. В результате на сервере Dns 1. microsoft . com оказались не отконфигурированными записи новых DNS -серверов, уполномоченных для домена lndia . microsoft . com , и запросыпродолжают пересылаться лишь на два DNS -сервера, заданный в начальномделегировании.
Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен,уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.
Другие примеры использования зон-заглушек
Зоны-заглушки могут использоваться для разрешения имен между доменами, предотвращая поиск родительского сервера в пространстве имен DNS. Зоны-заглушки, таким образом, заменяют дополнительные зоны в ситуациях, когда требуется обмен данными DNS между доменами без избыточности данных для главной зоны. Кроме того, зоны-заглушки оптимизируют процесс разрешения имен и снижают нагрузку сетевых ресурсов при передаче данных зон.
В этой статье я покажу, как делегировать домен, расскажу, что это значит, а также вы узнаете, что такое DNS. Вообще, новичкам это может показаться сложным, однако это придётся сделать для того, чтобы создать сайт. Делать это нужно всего один раз для каждого нового сайта. Потребуется также и при переносе с одного хостинга на другой или с локального сервера на реальный хостинг. В общем, вещь нужная и знать обязательно, хоть и трудно понять.
Для того чтобы рассказать, как делегировать домен, мне придётся начать издалека – с DNS.
DNS – это система доменных имён, в которой содержатся данные о том, какой IP у домена сайта, а следовательно, в какому хостингу он относится. Отсюда становится понятно – что если DNS настроена неправильно, то сайт работать не будет.
Итак, теперь переходим непосредственно к вопросу о том, как делегировать домен. Как вы должны были уже догадаться сами, под делегированием понимается присвоение доменному имени IP адреса сервера хостинга.
Делегирование домена, говоря простыми словами – это направление домена на хостинг. Данный процесс показывает, на каком хостинге находится тот или иной домен и откуда нужно закачивать файлы для отображения их в браузере посетителя.
Направление домена происходит с помощью назначения ему NS серверов хостинга (под NS кроется и IP, но он имеет совершенно иной вид). Перед тем, как делегировать домен, вам следует получить NS своего хостинга. Делается это в персональном кабинете хостинг-аккаунта. Покажу на скриншоте, как это выглядит на хостинге, на котором находится раньше находился мой сайт (). Если у вас другой хостинг, то у вас должно быть что-то похожее, но суть одинакова. NS бывает несколько – обычно 4 штуки.
Мои NS выглядят так:
ns1.hostinger.ru
ns2.hostinger.ru
ns3.hostinger.ru
ns4.hostinger.ru
Теперь переходим в персональный кабинет регистратора своего домена и записываем там полученный NS. Опять же, как делегировать домен я покажу на примере своего регистратора (). Если у вас другой, то кое-что будет отличаться, но суть одна и та же.
Прописывание NS от хостинга в панели управления домена – это и есть направление домена на хостинг. Теперь вы знаете, как делегировать домен, но не знаете ещё кое-чего.
Отдельная история – это обновление DNS. Понятно, что каждый день регистрируется множество доменных имён, кроме того, многие переезжают с одного хостинга на другой (с одного NS на другой). Поэтому система DNS должна постоянно обновляться, чтобы оставаться актуальной.
Обновление DNS происходит у каждого интернет-провайдера по-своему и не зависит ни от кого, кроме них самих. То есть, каждый интернет провайдер обновляет в своём собственном кэше информацию о привязанности того или иного доменного имени к какому-то хостингу. Делают это провайдеры редко – у некоторых может доходить до 1 раза каждые 72 часа.
Поэтому, если вы делегировали домен и прописали NS хостинга, сайт будет работать полноценно только через 72 часа. В течение этого времени он может в некоторых регионах уже работать, а в других ещё нет. Ругаться с поддержкой хостера или регистратора нет смысла. Также интернет-провайдер вам ничего не поможет. В этом случае нужно просто подождать, пока заданные вами NS распространятся по всему миру.
Если DNS у вашего провайдера ещё не обновились, а вам необходимо срочно начать работать на своём новом сайте, то можно сделать следующее. Переходим на компьютере в папку C:\Windows\System32\drivers\etc (где «С» — это диск, на котором установлено операционная система) и открываем файл hosts. Он без расширения, открыть его можно с помощью любого текстового редактора, например, блокнота. В файле hosts записываем следующие данные.
Тот человек, который хоть раз в самостоятельном порядке занимался делегированием домена (доменного имени) согласится, что тот , который был приобретен у одного , лучше будет размещать на сервере другого регистратора, который предоставляет услуги хостинга. С первого взгляда, кажется, что это весьма простая операция, которая не требует специальных знаний, но тот человек, который занимается проведением данной процедуры впервые, становится в ступор.
Для того чтобы дать ответ на столь важный вопрос, необходимо сначала четко понимать, что доменом является всего лишь персональный адрес вашего сайта, на который можно перейти с любого места на планете, которое имеет подключение к глобальной сети. Но для того чтобы домен начал полноценно работать его необходимо разместить на и осуществить его привязку к серверам данного хостинга, другими словами можно сказать, что производится процедура DNS подключения.
Для того что бы предоставить сайту максимально безопасную работу ему необходимо наличие двух DNSсерверов. Если один сервер перестанет полноценно работать, то данную задачу возьмет на себя второй DNS сервер. Следует понимать, что доступность вашего сайта является весьма важным показателем, который будет непосредственно влиять на размер вашей клиентской базы. Как выдумаете, вернется ли один и тот же посетитель к вам на сайт, если однажды ваш проект на протяжении даже не столь длительного времени был недоступным? А его недоступность может быть по причине отключения электроэнергии или негативных последствий стихийного бедствия, ситуации бывают разными, а вот итог будет одинаков.
Рассмотрим решение проблемы на конкретном примере. Доменное имя было приобретено у регистратора «1», а привязать его к хостингу необходимо регистратора «2». Вся суть проведения данного процесса заключается в том, что в конце процесса оформления доменного имени у регистратора «1» у вас потребуют предоставить адрес двух DNS серверов от регистратора «2», делается это для того, чтобы предоставить максимально надежную и стабильную работу вашего интернет — проекта. Из этого следует сделать вывод, что услуга хостинга от регистратора «2» должна быть заказана заблаговременно.
После того, как процесс регистрации доменного имени будет завершен, появится две и более ячейки, в которых необходимо будет разместить уже имеющиеся адреса DNS сервера для делегирования домена. Естественно, что эти ячейки можно оставить и пустыми, а заполнить их только после того, как будет принято решение относительно выбора хостера. Но пример будет рассмотрен в случае с заполнением двух ячеек.
К примеру, у вас имеется хостинг провайдер RU center, два сервера которого находятся в Амстердаме и в Москве, и для проведения процедуры делегирования необходимо прописать данные сервера. DNS 1: ns4.nic.ru (первая ячейка) и DNS 2: ns5.nic.ru (вторая ячейка). Вы можете прописать и третий адрес, к примеру, ns6.nic.ru , но данная процедура не является обязательной. Вместо DNS можно прописать и IP адрес, но данная ситуация никак не облегчает общий процесс. Но если вам так будет удобнее, то можете узнать IP адреса у службы поддержки регистратора, который предоставляет вам хостинг.
Для того чтобы проводить процедуру делегирования домена больше ничего не потребуется. После того как обновится информация относительно ситуации в доменных зонах, делегированный домен будет доступен для своего использования на указанном вами хостинге, и вы можете начать заполнять свой сайт .
Делегирование домена - это указание DNS-серверов, обеспечивающих его работоспособность. DNS-серверы должны быть заданы в настройках домена на сайте регистратора.
Внимание.
Вы можете делегировать домен на серверы Яндекса только после того, как добавили его в Почту для домена.
Чтобы делегировать домен на серверы Яндекса:
Для этого откройте страницу Мои домены и войдите в аккаунт, созданный для работы с ним. Проверьте наличие нужного домена.
Войдите в панель управления вашим доменом на сайте регистратора. Перейдите в раздел настроек делегирования.
Измените значения первичного и вторичного DNS-серверов следующим образом:
Первичный DNS-сервер - «dns1.yandex.net.» .
Вторичный DNS-сервер - «dns2.yandex.net.» .
Примечание. Буква «d» в начале имени DNS-серверов обязательна.
Если в панели управления есть поля для ввода IP-адресов, оставьте их пустыми.
Подождите, пока изменения в DNS вступят в силу. Этот процесс может длиться до 72 часов.
Проверьте статус вашего домена на странице Мои домены - его значение должно быть «Домен подключен и делегирован на Яндекс» .
Хостинг DNS и хостинг сайта - это две разные услуги, которые часто предоставляются хостинг-провайдерами одновременно. Но они никак между собой не связаны, поэтому вы можете безболезненно перенести хостинг DNS на серверы Яндекса. На работу сайта это не повлияет.
Когда вы делегируете домен на Яндекс, на серверах Почты для домена создаются A-записи, которые указывают на адрес хостинга вашего сайта. Если A-записи не были созданы автоматически, вы можете добавить их вручную в редакторе DNS :
В поле Хост укажите значение «@» , если вы настраиваете запись для корневого домена.
Если запись настраивается для поддомена, то в поле Хост нужно указать часть имени поддомена до первой точки, например:
если имя поддомена bar bar » ;
если имя поддомена foo.bar «foo.bar» .
в списке Тип выберите значение «A» (или «AAAA» , если сайт доступен по протоколу IPv6);
в поле Значение записи задайте IP-адрес нужного сайта.
Затем повторите процедуру для еще одной А-записи. Если вы настраиваете запись для корневого домена, в поле Хост укажите «www» . Если запись настраивается для поддомена, то в поле Хост нужно указать «www» и часть имени поддомена до первой точки, например:
если имя поддомена bar .yourdomain.tld, в поле Хост укажите « www.bar » ;
если имя поддомена foo.bar .yourdomain.com , в поле Хост укажите «www.foo.bar» .
Остальные поля настраиваются аналогично первой записи.
Основная цель DNS - это отображение доменных имен в IP адреса и наоборот - IP в DNS. Для чего же вообще нужна вся эта система? Компьютеры в сети общаются между собой, используя только IP-адреса. IP-адрес можно сравнить с номером телефона - чтобы один компьютер мог обратиться к другому, ему необходимо знать его IP-адрес. Однако у IP-адресов есть два недостатка: во-первых, их существует лишь ограниченное количество (что нам сейчас не очень важно), а во-вторых, что важнее, IP-адрес очень трудно запомнить человеку. Продолжая аналогию с телефонными номерами, помните ли вы номера телефонов всех своих друзей и знакомых? Вероятно, нет. Но вы всегда можете воспользоваться записной книжкой.
Доменная система имен была изобретена Полом Макпэтрисом по просьбе Джона Постэла в 1983 году, он же и выполнил первую ее реализацию. В 1984 году 4 студента из Беркли – Дуглас Тэрри, Марк Пэинтер, Дэвид Риггл и Содни Зу написали первую UNIX реализацию, которую они назвали Интернет Сервер Доменных Имен Беркли (Berkeley Internet Name Domain Server или сокращенно BIND). В 1985 году код этой реализации был существенно переписан Кевином Данлэпом, а в 1990 она была портирована на Windows NT. На данный момент BIND является самым используемым DNS сервером в мире.
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов.
«Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечают за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на сайте корневых серверов .
Зона - это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере . Зону, для бОльшего понимания, можно назвать «зоной ответственности» . Целью выделения части дерева в отдельную зону является передача ответственности (делегирование ) за эту ветвь другому лицу или организации.
Домен - это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Доменное имя начинается с точки (корневого домена ) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.е. доменное имя полностью отражаетструктуру иерархии DNS . Последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не site.nam e. , а site.name ).
Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN .
FQDN (англ. Fully Qualifed Domain Name , полностью определённое имя домена) - это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого . Своеобразный аналог абсолютного пути в файловой системе.
Давайте разберем вышесказанное на примере имени домена www.mydomain.com:
Максимальный размер FQDN - 255 байт, с ограничением в 63 байта на каждое имя домена.
Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names - зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др.
Вся DNS система построена на технологии клиент-сервер . Это значит, что существуют DNS-сервера , которые ждут запросов от пользователей, и есть DNS-клиенты , которые эти запросы посылают. Во всех браузерах имеется встроенный DNS-клиент, который и ответственен за перекодирование DNS имени в IP-адрес. После того как вы набираете что либо в адресной строке и нажимаете enter у него появляется работа. Изначально он знает о доменном имени не больше чем вы, поэтому-то он и начинает спрашивать. Рассмотрим процедуру получение ip-адреса на основе доменного имени.
Если пользователь обращается в течение короткого времени к одному и тому же ресурсу сети, то запрос на удаленный сервер не отправляется, а идет поиск информации в кэше. Порядок обработки запросов можно описать так: поиск ответа в локальном кэше -> поиск ответа на локальном сервере провайдера -> поиск информации в сети.
Данная схема является наиболее распространенной в сети и выглядит следующим образом:
Вот как происходит определение IP-адреса test-site.ru:
Loading root server list (static data): -> a.root-servers.net (198.41.0.4) -> b.root-servers.net (192.228.79.201) -> c.root-servers.net (192.33.4.12) -> d.root-servers.net (128.8.10.90) -> e.root-servers.net (192.203.230.10) -> f.root-servers.net (192.5.5.241) -> g.root-servers.net (192.112.36.4) -> h.root-servers.net (128.63.2.53) -> i.root-servers.net (192.36.148.17) -> j.root-servers.net (192.58.128.30) -> k.root-servers.net (193.0.14.129) -> l.root-servers.net (199.7.83.42) -> m.root-servers.net (202.12.27.33) Sending request to "f.root-servers.net" (192.5.5.241) Received referral response - DNS servers for "ru": -> e.dns.ripn.net (193.232.142.17) -> d.dns.ripn.net (194.190.124.17) -> a.dns.ripn.net (193.232.128.6) -> b.dns.ripn.net (194.85.252.62) -> f.dns.ripn.net (193.232.156.17) Sending request to "f.dns.ripn.net" (193.232.156.17) Received referral response - DNS servers for "test-site.ru": -> ns2.test-site.ru (5.9.195.91) -> ns1.test-site.ru (5.9.195.90) Sending request to "ns2.test-site.ru" (5.9.195.91) Timeout waiting for response Sending request to "ns1.test-site.ru" (5.9.195.90) Received authoritative (AA) response: -> Answer: A-record for test-site.ru = 5.9.195.90 -> Authority: NS-record for test-site.ru = ns1.test-site.ru -> Authority: NS-record for test-site.ru = ns2.test-site.ru -> Additional: A-record for ns1.test-site.ru = 5.9.195.90 -> Additional: A-record for ns2.test-site.ru = 5.9.195.91
На DNS-серверах информация хранится в виде ресурсных записей.
Ресурсная запись - это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена - IP адреса.
При этом, возможно использовать следующие символы:
Со всем набором ресурсных записей можно ознакомиться в wikipedia . Наиболее часто на практике применяемыследующиересурсные записи :
Пример : test-site.ru. A. 5.9.195.90. IN. 3600.
Пример :
test-site.ru. MX. 10. mx.yandex.ru. IN. 3600.
NAME | TTL | CLASS | TYPE | DATA |
MX.YANDEX.RU | 3600 | IN | MX | 10 |
Пример :
test-site.ru. NS. ns1.test-site.ru. IN. 3600.
test-site.ru. NS. ns2.test-site.ru. IN. 3600.
NAME | TTL | CLASS | TYPE | DATA |
TEST-SITE.RU. | 3600 | IN | NS | NS1.TEST-SITE.RU |
TEST-SITE.RU. | 3600 | IN | NS | NS2.TEST-SITE.RU |
- имя главного DNS (Primary Name Server)
- адрес администратора зоны
Далее - серийный номер файла зоны (Serial number ) . При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону.
Далее - значения таймеров (Refresh - указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry - время ожидания после неудачной попытки опроса, Expire - максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL - минимальное время, в течение которого данные остаются в кэше вторичного сервера).
Пример :
test-site.ru. SOA. test-site.ru. root.test-site.ru. 2013112923. 10800. 3600. 604800. 86400. IN. 3600.
NAME | TTL | CLASS | TYPE |
DATA (в соответствии с порядком выше) |
|||
TEST-SITE.RU. | IN | SOA | test-site.ru | root.test-site.ru | 2013112923 | 10800.3600.604800.86400 | |
test-site.ru. root.test-site.ru. 2013112923. 10800. 3600. 604800. 86400 |
Делегирование (корректнее сказать делегирование ответственности ) - это операция передачи ответственности за часть дерева доменных имен (зону) другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон.
Технически, делегирование - это внесение списка DNS-серверов, на которых должна быть размещена техническая информация о домене (файл зоны), на DNS-серверы, обеспечивающие работу доменов верхнего уровня. Делегирование является необходимым условием работы сайта и почты на домене.
Делегирование домена производится при помощи изменения NS – записей домена, в которых указывается адрес DNS-сервера, который принадлежит третьему лицу и отвечает за поддержание доменной зоны. Диапазоны IP-адресов делегируются с помощью доменной зоны in-addr.arpa.
В связи с техническими особенностями фунционирования системы преобразования доменных имен после установки для домена DNS-серверов домен проделегируется на них не сразу. Несмотря на то, что почти в тот же момент информация на whois-сервере изменится, локальные DNS-серверы интернет-провайдеров получат ее только через некоторое время.
Опытным путем установлено, что на делегирование домена, т.е. на распространение информации о новых DNS среди интернет-провайдеров нашей планеты, требуется около 24 часов. Но не стоит удивляться, если после смены DNS-серверов Вы сможете увидеть рабоспособный сайт на Вашем домене намного раньше. Это обычная практика, и 24 часа - это максимальный промежуток времени, требуемый на делегирование домена.
В двух словах хотел бы затронуть вопросрегистрации доменных имен .
Регистрация доменов - это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.
Регистратор доменных имён - это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:
Регистратором для корневого домена является организация ICANN . Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), необходимо получить аккредитацию ICANN.
https://www.nic.ru/whois/ - проверка доменов (основные сведения)
http://www.cy-pr.com/tools/dns/ - расширенные сведения по ДНС