Доменное имя сервера

Что такое ДНС (DNS)?

Интернет — это совокупность локальных сетей компьютеров, расположенных по всему миру, которые связываются между собой по единым правилам, называемым протоколами.

Для того, чтобы не запоминать числовой адрес компьютера, была создана система DNS. Система Доменных Имен или DNS (Domain Names System), связывает имена, подобные www.htmlweb.ru c цифровыми адресами(185.12.92.137), которые используют компьютеры, чтобы связываться друг с другом.

Для того, чтобы Ваш сайт с Вашим доменным именем заработал — необходимо указать DNS-сервера, на которых будет «записано», на каком именно сервере(хостинге) находится Ваш сайт. DNS сервера имеют вид:

ns1.yourhosting.ru
ns2.yourhosting.ru

Есть три пути настроки DNS:

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

Как указать (изменить) DNS-сервера для домена?

Для указания/изменения DNS-сервера у домена, то Вам необходимо:

1. зарегистрироваться у регистратора домменых имен;
2. Найти нужный домен и выбрать там «Управление DNS-серверами / Делегирование»
3. В открывшейся форме укажите нужные DNS-сервера (IP можно не указывать). или установите галочку «Использовать DNS-сервера регистратора».
4. Нажмите на кнопку «Сохранить».

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

Настрока DNS-записей.

Для внесения/изменения записей на DNS сервере Вам необходимо сделать следующее:

1. Авторизуйтесь в панели управления Вашего хостинга DNS Найдите нужный домен и выберите там «Управление зоной DNS»
2. В открывшейся форме Вы можете вносить записи типа A, CNAME и другие в зоны DNS.
3. После внесения записей нажмите на кнопку «Сохранить/Добавить».

Пример внесения записей в DNS:

Предположим, вы зарегистрировали домен mydomain.ru и IP-адрес web-сервера, на котором будет расположен сайт — 195.128.128.26. В этом случае Вам потребуется создать минимум две записи типа «A» для Вашего домена (чтобы связать mydomain.ru и www.mydomain.ru с адресом 195.128.128.26). Для этого в форме добавления записей «A» в поле «Имя поддомена» укажите «@» для первой записи и «www» для второй записи, а в поле «Данные» укажите 195.128.128.26 (для обоих записей).

Чтобы сделать пересылку всех поддоменов на IP адрес, нужно в качестве «Имени поддомена» указать *

Пример 2: Вы хотите, чтобы адрес mail.mydomain.ru указывал на тот же хост, что и адрес relay.highway.ru. Для этого необходимо в поле ‘Имя поддомена’ указать «mail», выбрать ‘Тип записи’ CNAME, а в поле ‘Данные’ указать «relay.highway.ru.».

Пример DNS-записей для зоны mydomain.ru:

 @ A 195.161.114.80 @ MX 10 relay.highway.ru. www A 195.161.114.80 ctrl CNAME ctrl.muse.highway.ru. ftp CNAME ftp.muse.highway.ru. mail CNAME relay.highway.ru. ssh CNAME ssh.muse.highway.ru. 

Смотрите также: настрока Яндекс-почты для домена.

Инструкции по смене DNS-серверов

1. Если вы указываете у домена RU, SU, РФ DNS-сервера, которые расположены в этом же домене (т.е. «свои» DNS), например, для домена testsite.ru вы указываете DNS-сервера ns1.testsite.ru и ns2.testsite.ru, то обязательно необходимо указать для каждого DNS-сервера его IP адрес.


2. Если вы указываете у любого домена DNS-сервера, которые расположены в другом домене, например, для домена testsite.ru вы указываете DNS-сервера ns1.abrakadabra.ru и ns2.abrakadabra.ru, то указывать для каждого DNS-сервера IP адреса не нужно.
3. IP адреса у DNS-серверов (в случае необходимости их указания, см. выше) для доменов RU, SU, РФ должны отличаться хотя бы на одну цифру! Одинаковые IP для всех DNS не допустимы.
4. Для международных доменов (com, net, org, info и т.п.) DNS-сервера, которые вы указываете у домена, должны быть обязательно зарегистрированы в международной базе NSI Registry. Если они там не зарегистрированы, то указать их нельзя. Для международных доменов IP адреса у DNS-серверов указывать не нужно. Они указываются при регистрации DNS в базе NSI Registry

Как прикрепить домен к IP адресу?

Для того, чтобы прикрепить домен к IP адресу, Вам необходимо:

1. зайти в настроку dns-записей и внести в зону DNS три записи:
   • Для первой в качестве поддомена укажите www, выберите тип записи А, в качестве данных укажите IP адрес, к которому нужно прикрепить домен.
   • Для второй записи укажите знак @ (собака) в качестве поддомена и так же выберите тип А и укажите тот же IP.
   • Для третьей записи в качестве поддомена укажите знак * (звёздочку) и так же выберите тип А и укажите тот же IP.
2. Нажмите «Добавить/Сохранить»

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

Как долго происходит изменение DNS?

Сами изменения в DNS вносятся моментально. Но в связи с тем, что провайдеры кэшируют DNS, то процесс изменения DNS по всему миру может занять время от нескольких минут до 72 часов.

htmlweb.ru

Ключевые характеристики DNS[править | править код]

DNS обладает следующими характеристиками:

• Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
• Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
• Кэширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
• Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
• Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности[править | править код]

• поддержка динамических обновлений
• защита данных (DNSSEC) и транзакций (TSIG)
• поддержка различных типов информации

История[править | править код]

Использование более простого и запоминающегося имени вместо числового адреса хоста относится к эпохе ARPANET. Стэнфордский исследовательский институт (теперь SRI International) поддерживал текстовый файл HOSTS.TXT, который сопоставлял имена узлов с числовыми адресами компьютеров в ARPANET. Поддержание числовых адресов, называемых списком присвоенных номеров, было обработано Джоном Постелем в Институте информационных наук Университета Южной Калифорнии (ISI), команда которого тесно сотрудничала с НИИ.^[1]

Адреса назначались вручную. Чтобы запросить имя хоста и адрес и добавить компьютер в главный файл, пользователи связывались с сетевым информационным центром (NIC) SRI, руководимым Элизабет Фейнлер, по телефону в рабочее время.

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

Рабочая группа IETF опубликовала оригинальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года.

В 1984 году четыре студента UC Berkeley, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонгниан Чжоу, написали первую версию сервера имен BIND (Berkeley Internet Name Daemon). В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карел, Фил Альмквист и Пол Викси поддерживали BIND с тех пор. В начале 1990-х годов BIND был перенесен на платформу Windows NT. Он широко распространен, особенно в Unix-системах, и по-прежнему является наиболее широко используемым программным обеспечением DNS в Интернете.

В ноябре 1987 года были приняты спецификации DNS — RFC 1034 и RFC 1035. После этого были приняты сотни RFC, изменяющих и дополняющих DNS.

Проблемы с безопасностью[править | править код]

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

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

DNS-ответы ранее не имели криптографической подписи, что давало возможность для множества вариантов атаки. Современные расширения системы безопасности доменных имен (DNSSEC) изменяют DNS, чтобы добавить поддержку криптографически подписанных ответов. Другие расширения, такие как TSIG, добавляют поддержку криптографической аутентификации между доверенными одноранговыми узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.

Некоторые доменные имена могут использоваться для достижения эффектов спуфинга. Например, paypal.com и paypa1.com — это разные имена, но пользователи могут не различать их в графическом пользовательском интерфейсе в зависимости от выбранного шрифта пользователя. Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема остро стоит в системах, которые поддерживают интернационализированные доменные имена, поскольку многие коды символов в ISO 10646 могут отображаться на типичных экранах компьютеров. Эта уязвимость иногда используется в фишинге.

Для подтверждения результатов DNS также могут использоваться такие методы, как обратный DNS с подтверждением прямых записей, но криптографически достоверными они не являются; при этом не учитывается вариант подмены маршрутной информации (англ. BGP hijacking).

Терминология и принципы работы[править | править код]

Ключевыми понятиями DNS являются:

• Доме́н (англ. domain «область») — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имён. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вверху находится корневой домен (имеющий идентификатор «.
  
  »(точка)), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго — wikipedia, третьего — ru). DNS позволяет не указывать точку корневого домена.
• Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.
• Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определённому доменному имени, узлу в дереве имён), тип и поле данных, формат и содержание которого зависит от типа.


• Зона — часть дерева доменных имён (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имён (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже). Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации. Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имён DNS как структуру из зон, а не отдельных узлов/имён, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчинённых. На практике большинство зон 0-го и 1-го уровня (‘.’, ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчинённых уровней без выделения их в дочерние зоны.
• Делегирование — операция передачи ответственности за часть дерева доменных имён другому лицу или организации. За счёт делегирования в DNS обеспечивается распределённость администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.
• DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
• DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
• Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
• DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).

Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.

Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.^[2]

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.

Рекурсия[править | править код]

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

DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.

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

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

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

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако сервер DNS может ничего не знать не только о запрошенном имени, но и даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

• браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
• DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
• остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).

Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.

При рекурсивной обработке запросов все ответы проходят через DNS-сервер, и он получает возможность кэшировать их. Повторный запрос на те же имена обычно не идёт дальше кэша сервера, обращения к другим серверам не происходит вообще. Допустимое время хранения ответов в кэше приходит вместе с ответами (поле TTL ресурсной записи).

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

Обратный DNS-запрос[править | править код]

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Записи DNS[править | править код]

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей^[3]:

• имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
• тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
• класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети^[4],
• TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
• длина поля данных (RDLEN),
• поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

• Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
• Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
• Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись PTR (pointer^[5][6]) обратная DNS-запись или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
• SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Зарезервированные доменные имена[править | править код]

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Интернациональные доменные имена[править | править код]

Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

Программное обеспечение DNS[править | править код]

Серверы имен:

• BIND (Berkeley Internet Name Domain) [1]
• djbdns (Daniel J. Bernstein’s DNS) [2]
• Dnsmasq [3]
• MaraDNS [4]
• NSD (Name Server Daemon) [5]
• PowerDNS [6]
• OpenDNS [7]
• Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
• MyDNS [8]

См. также[править | править код]

• Атака Каминского
• Альтернативные корневые серверы DNS
• OpenDNS
• Google Public DNS
• Яндекс.DNS
• Киберсквоттинг
• Тайпсквоттинг
• Динамический DNS
• Round robin DNS — распределение нагрузки между одинаковыми серверами.
• ICANN
• DNSSEC
• DNS-клиент
• DNS-сервер
• Nslookup

Ссылки[править | править код]

• DNS Resources Directory  (англ.)
• Ресурсы, посвящённые DNS & BIND  (англ.)
• Общество CircleID DNS  (англ.)
• Повышение безопасности DNS (DNSSEC)  (англ.)
• Рабочий комитет IETF занимающийся разработкой расширенной спецификации DNS (DNSEXT)  (англ.)
• Сайт корневых DNS-серверов  (англ.)
• Просмотр DNS-записей домена
• Веб-инструменты для DNS, каталог на сайте dmoz.org  (англ.)

Статьи[править | править код]

• Обзор схем и типов DNS-атак

ru.wikipedia.org

Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

• Всего множества доменных имен (domain name space)
• Серверов доменных имен (domain name servers)
• Клиенты DNS (Resolver-ы)

Множество доменных имен было подробно рассмотрено в материале «Доменная адресация. Немного истории и принципы построения», поэтому сосредоточимся на двух оставшихся компонентах серверах и resolver-ах.

Сервис системы доменных имен строится по схеме «клиент-сервер». В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени). Это программное обеспечение и называют resolver. В качестве сервера выступает прикладная программа-сервер.

Чаще всего, Resolver не является какой-либо программой или системной компонентой. Это набор процедур из библиотеки прикладного программного обеспечения (например, из библиотеки libc), которые позволяют программе, отредактированной с ними, выполнять запросы к системе доменных имен и получать ответы на них. Эти процедуры обращаются к серверу доменных имен и, таким образом, обслуживает запросы прикладных программ пользователя.

Ряд производителей операционных систем, например, Sun или SGI, предлагали решения, в которых resolver являлся отдельным процессом, и прикладные программы через него реализовывали взаимодействие с DNS.

Другой пример реализации resolver-а — это браузеры Nescape некоторых версий, где для ускорения процесса получения ответов на запросы к DNS запускался отдельный процесс resolver-a.

Самостоятельный resolver может быть собран и в BIND версии 9. Это так называемый lightweight resolver. Он состоит из rosolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО. Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.

В качестве серверов доменных имен чаще всего используются различные версии BIND (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.

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

Рис1. Рекурсивный запрос resolver и нерекурсивная (итеративная) процедура на разрешение доменного имени сервером доменных имен.

Данная схема разрешения имени (установки соответствия между именем и IP-адресом) называют нерекурсивной (итеративной). Чем она отличается от рекурсивной мы обсудим позже.

Поясним приведенную схему нерекурсивной процедуры разрешения запроса:

1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес).
2. Местный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:
   
   1. если адрес находится в зоне его (местного сервера) ответственности, сразу сообщает его resolver-у,
   2. если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server),
   3. обращается к TLD-серверу за адресом,
   4. получает от него адрес удаленного сервера,
   5. обращается к удаленному серверу за адресом,
   6. получает от удаленного сервера адрес,

В данном случае мы рассмотрели вложенность доменного имени второго порядка., т.е. хост имел имя похожее на quest.kuku.ru или даже kuku.ru.

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

Если вложенность доменного имени будет большей, скажем третьего уровня (host.department.corp.ru), и этот уровень будет поддерживаться другим сервером доменных имен, отличным от того, который поддерживает второй уровень вложенности, то тогда нашему локальному серверу удаленный сервер доменных имен передаст не адрес хоста, а адрес нового сервера доменных имен, в зоне ответственности которого находится запрашиваемое имя.

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

При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:

 /usr/paul>telnet polyn.net.kiae.su 

Мы получаем в ответ:

 /usr/paul>telnet polyn.net.kiae.su trying 144.206.130.137 ... login: ..... 

Строчка, в которой указан IP-адрес компьютера polyn.net.kiae.su, показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен и прикладная программа, в данном случае telnet получила на свой запрос IP-адрес. Таким образом, после ввода команды с консоли, и до появления IP-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.

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

Другой пример того же сорта — это программа traceroute. Здесь задержка на запросы к серверу доменных имен проявляется в том, что время ответов со шлюзов, на которых «умирают» ICMP пакеты, указанное в отчете, маленькое, а задержки с отображением каждой строчки отчета довольно большие.

Любопытно, что в системе Windows 3.1 некоторые программы трассировки, показывали сначала IP-адрес шлюза, а только потом, после разрешения «обратного» запроса, заменяли его на доменное имя шлюза. Если сервис доменных имен работал быстро, то эта подмена была практически незаметна, но если сервис работал медленно, то промежутки бывали довольно значительными.

Проверить на сколько «чувствительны» запросы traceroute c точки зрения отображения трассы к использованию сервера доменных имен можно задав поиск трассы с использованием сервера:

 >traceroute www.w3.org 

и без использования сервера:

 >traceroute -n www.w3.org 

Если в примере с telnet и ftp мы рассматривали, только «прямые» (forward) запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули «обратные»(reverse) запросы. В «прямом» запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При «обратном» запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

Следует заметить, что скорость разрешения «прямых» и «обратных» запросов в общем случае будет разная. Все зависит от того, где описаны «прямые»(forward) и «обратные»(reverse) зоны в базах данных серверов доменных имен, обслуживающих соответствующие домены (прямой и обратный).

Более подробно этого вопроса мы коснемся при обсуждении файлов конфигурации программы named.

Однако вернемся к обсуждению схемы работы системы доменных имен. Собственно нерекурсивным рассмотренный выше запрос является только с точки зрения сервера. С точки зрения resolver-а процедура разрешения запроса является рекурсивной, так как resolver перепоручил локальному серверу доменных имен заниматься поиском необходимой информации. Согласно RFC-1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы.

В этом случае resolver обращается к локальному серверу доменных имен, если не получает от него адреса, то опрашивает сервер корневого домена, получает от него адрес удаленного сервера TLD, опрашивает этот сервер, получает адрес удаленного сервера, опрашивает удаленный сервер и получает IP-адрес, если он посылал, так называемый «прямой» запрос.

Рис.2. Нерекурсивный запрос resolver-а.

Как видно из этой схемы, resolver сам нашел нужный IP-адрес. Однако общая практика такова, что resolver не порождает нерекурсивных запросов, а переадресовывает их локальному серверу доменных имен.

Локальный сервер и resolver не все запросы выполняют по указанной процедуре. Дело в том, что существует кэш, который используется для хранения в нем полученной от удаленного сервера информации.

Самые умные resolver-ы, такие, например, как resolver Windows 2000 Server и BIND 9 умеют поддерживать кэш, в котором сохранияют не только удачно установленные соответствия имени и адреса (positive response), но и так называемые «негативные» отклики (negative response results) на запросы. Кроме того, эти resolver-ы упорядочивают отклики об адресах серверов в соответствии с принятыми в них (resolver-ах) алгоритмами выставления предпочтений, которые базируются на времени отклика сервера.

Рис.3. Схема разрешения запросов с кэшированием ответов.

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

Вообще говоря, прядок обработки запросов можно описать следующим образом:

1. поиск ответа в локальном кэше
2. поиск ответа на локальном сервере
3. поиск информации в сети.

При этом кэш может быть как у resolver-а, так и у сервера.

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

Между доменом и зоной существует разница, которую бывает трудно найти, но всегда нужно иметь в виду. Домен — это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Зона — это «зона ответственности» конкретного сервера доменных имен, т.е. понятие домена шире, чем понятие зоны. Если домен разбивается на поддомены, то у каждого из них может появиться свой сервер. При этом зоной ответственности сервера более высокого уровня будет только та часть описания домена, которая не делегирована другим серверам. Разбиение домена на поддомены и организация сервера для каждого из них называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

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

Существует еще и другой вариант работы сервера, когда он не запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен. Это происходит тогда, когда незадолго до этого сервер уже разрешал задачу получения IP-адреса из того же домена. Если требуется получить IP-адрес удаленного сервера доменных имен, отвечающего за домен, то он будет просто извлечен из буфера сервера (кеша), т.к. в течение определенного времени, заданного в конфигурации описания зоны (Time To Live — TTL), этот адрес будет храниться в кэше сервера. А попал он туда как результат выполнения предыдущего запроса.

Кроме нерекурсивной процедуры разрешения имен возможна еще и рекурсивная процедура разрешения имен. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим этот случай более подробно.

На рисунке 4 продемонстрирована нерекурсивная процедура разрешения IP-адреса по доменном имени. Основная нагрузка в этом случае ложится на местный сервер доменных имен, который осуществляет опрос всех остальных серверов. Для того, чтобы сократить число таких обменов, если позволяет объем оперативной памяти, можно разрешить буферизацию (кэширование) адресов. В этом случае число обменов с удаленными серверами сократится.

На рисунке 5 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена по рекурсивному запросу, используя при этом нерекурсивный опрос своих серверов поддоменов.

Рис 4. Нерекурсивная обработка запроса местным сервером доменных имен на получение IP-адреса по доменному имени.

Рис. 5. Рекурсивная (для местного сервера) и нерекурсивная (для удаленного сервера) процедуры разрешения адреса по IP-имени.

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

Представленные здесь варианты работы системы доменных имен не являются исчерпывающими. За более подробной информацией следует обращаться к RFC-1034 и RFC-1035.

Рекомендованная литература:

1. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.

Полезные ссылки:

1. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_und_HowDnsWorks.htm?id=1945 — Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы системы доменных имен. Описывает общие принципы построения DNS и взаимодействия resolver и серверов.
2. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_ovr_ClientFeatures.htm?id=1942 — Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы resolver.
3. http://www.nominum.com/resources/documentation/Bv9ARM.pdf — Документация по BIND 9. Справочное руководство системного администратора. Нужно ознакомиться с разделом, посвященном lightweight resolver.
4. http://www.igc.ru/cgi-bin/man-cgi?traceroute — описание команды traceroute, раз уж ее здесь упомянули.
5. http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm — глоссарий терминов DNS.

info.nic.ru

Домены верхнего уровня

Домены верхнего уровня еще называют доменными зонами. Например, в доменном имени likbez-net.ru,  .ru –это домен верхнего уровня.

Все домены верхнего уровня можно разделить на две группы:

— национальные или географические домены, они определяют принадлежность сайта к той или иной стране или географической территории. Например,  домен .ru  принадлежит России, .kz — Казахстану, .ua – Украине и пр.

— домены общего пользования. Они могут  устанавливают  принадлежность сайта к определенной категории или виду деятельности. Например .com – коммерческие, .info – информационные, .biz – для бизнеса, .org – некоммерческие, .travel – туризм  и пр.

Основой для российской зоны Интернета (Рунета)  является домен .RU. Именно он дает возможность регистрировать разнообразные доменные имена для Рунета за счет появления доменов второго уровня.

Домены второго уровня

Название моего сайта blondinka-net.ru является доменным именем второго уровня.  Здесь .RU — это домен верхнего уровня. Собственное имя web-сайта – likbez-net находится на втором месте от окончания полного имени. Именно поэтому такие домены называются доменами второго уровня.

Второй и все последующие уровни домена имеют важное ограничение — они должны быть уникальны в группе своего родительского домена. Иначе говоря, в Интернет может быть только один домен второго уровня likbez-net в домене верхнего уровня .ru .

Доменные имена второго уровня регистрируются у организаций-регистраторов.

RU-Center PeterHost Хостинг – Центер Jino R01 Reg.RU MasterName RegTime

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

Домены третьего уровня

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

Обладатель домена второго уровня имеет возможность создавать неограниченное количество адресов третьего и далее уровней. Так, например,  я как владелец домена второго уровня likbez-net.ru, могу создать домен для форума forum.likbez—net.ru. Получилось  доменное имя третьего уровня, и forum является доменом третьего уровня в зоне likbez—net.ru.

Обычно, услугу регистрации домена третьего уровня предоставляют провайдеры – поставщики интернет услуг.

< Что такое HTML-код страницы?		Что такое CMS? >

 

likbez-net.ru

URL является подмножеством URI (см. выше). Якорь — ссылка не на документ, а на место в самом документе.

Для чего это нужно? Давайте представим, что решили мы посетить Пикабу… Мы набираем pikabu.ru, браузер добавляет «обвес» и находит сайт по ссылке http://pikabu.ru . Если нет взлома, то каждый раз с каждого устройства будет открываться один и тот же файл (а страница сайта — это файл) в сети. URI — маяки в сети.

Итак рассмотрим полные URI адреса. В один, к сожалению, не получится:

http://ccc.bbb.aaa.example.com.:8080/file/example.php?login=admin&pass=admin

Читаем адрес правильно:

. — точка между com и :8080 является обозначением корня доменной системы имен. Поскольку она есть во всех адресах её обычно не используют, однако, например при настройке доменных зон, отсутствие этой точки приводит к ошибкам. За эту точку отвечает аж целая международная организация (ICANN — Internet Corporation for Assigned Names and Numbers или Корпорация по управлению доменными именами и IP-адресами). Это связано с простым правилом — тот кто владеет доменной зоной, тот может делать в ней все что угодно…

.com — домен первого (или как некоторые говорят верхнего) уровня. Выделяются соответственно ICANN.

example — домен второго уровня. Выделяется регистратором который договорился с ICANN на выделение имен в соответствующей зоне.

aaa — домен 3-го уровня. Выделяется владельцем домена второго уровня.

bbb — домен 4-го уровня. Выделяется владельцем домена третьего уровня.

ccc — домен 5-го уровня. Выделяется владельцем домена четвертого уровня.

:8080 — порт на который происходит подключение. Остановимся на понятии «порт» поподробнее. Дело в том, что к одному серверу может быть одновременно подключено несколько клиентов к разным программам запущенным на сервере. Так вот чтобы данные клиентов и программ не пересекались с данными других клиентов и программ данные маркируются особой меткой которая и называется «порт». Порты с номерами до 1024 зарезервированы для «стандартных» программ.

http — протокол передачи данных.

/file — каталог/папка на сервере в которой лежит

/example.php — файл на сервере, который получает:

?login=admin&pass=admin — параметры login и pass со значением admin.

Второй пример:

ftp://admin:admin@ccc.bbb.aaa.example.com.:21/file/example.doc

Пересечения с первым описывать не буду, отмечу только отличия: логин и пароль выведены в URI и сменен протокол.

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

Сколько стоит

Цены на домены устанавливают регистраторы доменных имен. Стоимость домена 2 уровня начинается (для ru/рф зоны) от 95 рублей. Различные регистраторы предлагают различные цены, но для клиента важно только одно — верификация домена (привязка имени к конкретному физическому или юридическому лицу). Внимание! Некоторые регистраторы раздают домены бесплатно, но при этом или регистрируют их на себя или оставляют управление доменом за собой. Если сайт раскрутится, то регистратор может просто продать раскрученный домен конкурентам.

Зачем оно нужно

Доменная зона второго уровня, это престиж, выгода и удобство. Согласитесь, что почта boss@example.ru гораздо солидней выглядит, чем boss_example@mail.ru. Выгода заключается в том, что владелец зоны второго уровня может «открыть миру» свой сайт, почтовый сервис, обмен сообщениями, файловое хранилище и т. п. При этом указанные сервисы могут быть монетизированы и приносить прибыль (Mail.ru начинался как простой почтовик).

А вот на теме удобства стоит остановиться поподробней.

Во-первых это сайт. Сайт — система автоматизации, пассивная реклама и пассивный источник клиентов. Первые 3-4 месяца он работает вхолостую, но потом будет кого-нибудь да и подкидывать. Количество клиентов с сайта сильно зависит во-первых от раскрутки, во-вторых от полноты и качества информации. «Мы Вам перезвоним» — это около 80% отказов т. к. не льстите себе, Вы далеко не монополист (Газпром с Ростелекомом извините) и раз человек ищет что-то ему проще открыть следующий за Вами сайт, чем оставлять заявку и ждать менеджеров. Практика наблюдения показывает, что человек перебирает сперва полные варианты, и если не нашел нужного оставляет заявку на связь. Грамотно созданный сайт —уменьшение трудозатрат продажников, хороший поток клиентов, при этом клиентов которые уже получили большинство нужной информации и уже готовы что-нибудь купить. Ошибки в сайте и продажников начинают заваливать уточняющими звонками, вопросами… Люди очень заняты, но продажи при этом стоят. Эффективный сайт может сэкономить 75% времени сотрудников отдела продаж т. е. если продажник без сайта приводит 10 клиентов в месяц, то с хорошим сайтом он приведет до 40.

Ремарка: в сайтостроительстве наблюдается нашествие ширпотреба. Подавляющее большинство сайтов — откровенный шлак, причем, что самое главное — больше всего шлака идет от «элитных» веб-студий. «Лох не мамонт» — со стороны заказчиков крайне редко можно встретить специалистов которые способны адекватно оценить качество работы. Это приводит к тому, что с каждым годом профессионалов в сфере сайтостроения остается все меньше и меньше. В сухом итоге со стороны заказчика это во-первых финансовые потери, а во-вторых скоро получить качественный сайт будет просто невозможно из-за отсутствия специалистов…

Во-вторых это корпоративная электронная почта и какие у неё преимущества думаю знает и понимает каждый. Для своего домена корпоративная почта это прежде всего свобода. «На старте» свободными являются все имена в домене, то есть можно выбрать любое красивое и звучное имя, а не регистрировать после перебора всех красивых вариантов vasya9999@yandex.ru.

В-третьих URI позволяет твердо зафиксировать документ или ресурс. Это значит, что все типовые коммерческие предложения, презентации, буклеты и т. п. можно выложить на сервере/хостинге и рассылать не письма, а ссылки на них. В особо продвинутых организациях есть грамотно настроенная (если нет человека который все грамотно сделает, то не делайте — иначе взлом Вашей сети станет обыденностью) адресация по типу: сотрудник.отдел.домен, при правильной настройке подключения это позволяет во-первых обращаться к компьютерам напрямую (в т.ч. из локальной сети), а во-вторых сотруднику работать за компьютером из любого места где есть интернет.

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

В-пятых домен позволяет создавать сеть между удаленными точками (VPN). В единый домен могут быть включены разные офисы и удаленные рабочие места.

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

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

Баянометр опять сломался…

P.S. Извиняюсь за сумбурность, позавчера (хотя узнал недавно) на 29-м году жизни внезапно не стало моего коллеги Димы и данный пост был написан как отдушина, потому как в такие моменты нужно просто отвлечься.

pikabu.ru

Просмотр списка доменов

• Доменное имя — основное имя домена, поддерживаемое данной доменной зоной.
• Владелец — имя пользователя, которому принадлежит домен. Не отображается на уровне пользователя ISPmanager.

Создание нового домена

Чтобы создать новое доменное имя, нажмите кнопку «Создать» и заполните следующую форму:

Если не установлен флаг Владельцем являются администраторы, то отображаются следующие поля:

• Владелец — выберите пользователя, который может управлять данной доменной зоной. Данное поле доступно только на уровне администратора ISPmanager.
• Доменное имя — укажите основное имя домена, поддерживаемое данной доменной зоной. Все записи данной доменной зоны должны иметь вид запись.доменное_имя. Значение этого поля должно соответствовать правилам составления доменных имён, например: example.com, web-site.org, test.example.com.
• Источник IP-адресов — выберите, как вы хотите добавить IP-адрес. Вы можете либо указать его вручную, либо выбрать из списка имеющихся.
• IP-адреса — укажите IP-адрес, к которому будет привязан данный домен.
• Создать WWW домен — установите флажок, чтобы данное доменное имя было доступно через WWW, и посетители могли обращаться к web-страницам из своих браузеров.
• Создать почтовый домен — установите флажок, чтобы создавать почтовые ящики в домене с таким именем. В этом случае автоматически будет создан почтовый домен с таким же именем, принадлежащий тому же владельцу.

Если установлен флаг Владельцем являются администраторы, то отображаются следующие поля:

• Доменное имя — укажите основное имя домена, поддерживаемое данной доменной зоной. Все записи данной доменной зоны должны иметь вид запись.доменное_имя. Значение этого поля должно соответствовать правилам составления доменных имён, например: example.com, web-site.org, test.example.com.
• Источник IP-адресов — выберите, как вы хотите добавить IP-адрес. Вы можете либо указать его вручную, либо выбрать из списка имеющихся.
• IP-адреса — укажите IP-адрес, к которому будет привязан данный домен.

Редактирование параметров домена

Чтобы изменить параметры существующего домена, выберите его из списка, нажмите кнопку «Изменить» и выполните редактирование. Форма для редактирования аналогична форме создания нового домена.

Удаление домена

Чтобы удалить домен, выберите его из списка и нажмите кнопку «Удалить». Для предотвращения случайного удаления программа попросит подтвердить или отменить ваши действия. После нажатия кнопки «ОК» выделенный домен будет удален.

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

Настройка доменов по умолчанию

Функция доступна только для администратора и для реселлера ISPmanager.

Вы можете задавать настройки по умолчанию для вновь создаваемых доменных зон, а также изменять настройки для существующих. Для этого нажмите кнопку «Настройка» и заполните следующую форму:

• Серверы имён — укажите список доменных имён DNS-серверов, которые будут автоматически использоваться для вновь создаваемых доменов. Их вы указываете у регистратора доменных имён. Если вы указываете полное доменное имя, необходимо поставить точку «.» на конце (ns1.mydomain.com. ns2.mydomain.com.).
• Email администратора — email адрес администратора, который указывается в SOA создаваемых доменных зон.
• Применить к существующим — установите флажок, чтобы применить настройки для всех существующих на сервере доменных зон.
• Поддомены — список разделённых пробелом поддоменов, которые будут автоматически добавляться при создании каждого нового домена.
• Почтовые серверы — список доменных имён серверов, управляющих электронной почтой данного домена. Также это может быть список записей данного домена. Поле может содержать любое количество доменных имён, удовлетворяющим требованиям, предъявляемым к доменным именам. Если вы указываете полное доменное имя, необходимо поставить точку «.» на конце (mail1.mydomain.com. mail2.mydomain.com.). Если это запись в текущем домене, точку ставить не нужно (mail mail).
• IP-адреса серверов имен — если NS-запись лежит в пределах создаваемой доменной зоны, для NS-серверов будут автоматически созданы A и AAAA записи. Если этот параметр задан, то IP-адреса для ns-записей будут взяты из него. Если параметр не задан, то для первой ns-записи будет взят IP-адрес master-зоны, а для всех остальных IP-адрес slave-зоны (при использовании вторичных серверов имён). Если вторичные серверы имён не настроены или в параметре NsIps будет недостаточное количество IP-адресов, будет получена ошибка — «Возникла ошибка при работе с DNS. Не хватает ip-адресов для серверов имен. Необходимое количество: ‘Х'» Поле недоступно из-под реселлера.
• Имя сервера для SOA-записей — укажите значение для SOA-записей, если необходимо, чтобы имя сервера, определяемое в SOA-записях (MNAME), отличалось от имени хоста сервера, обслуживающего запросы DNS. Если вы не уверены в необходимости для вас этой настройки, оставьте данный параметр пустым! Поле недоступно из-под реселлера.

doc.ispsystem.ru