server name что это
Имена сервера
Имена сервера задаются с помощью директивы server_name и определяют, в каком блоке server будет обрабатываться тот или иной запрос. См. также “Как nginx обрабатывает запросы”. Имена могут быть заданы точно, с помощью маски или регулярного выражения:
При поиске виртуального сервера по имени, если имени соответствует несколько из указанных вариантов, например, одновременно подходят и имя с маской, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета:
Имена с масками
Имя с маской может содержать звёздочку (“ * ”) только в начале или в конце имени, и только на границе, определяемой точкой. Имена “ www.*.example.org ” и “ w*.example.org ” являются некорректными, но их можно задать с помощью регулярных выражений, например, “
Имена, заданные регулярными выражениями
Регулярные выражения, используемые в nginx, совместимы с используемыми в языке программирования Perl (PCRE). Имя сервера, заданное регулярным выражением, должно начинаться с символа тильды:
иначе nginx откажется запускаться и выдаст сообщение об ошибке:
К именованному выделению в регулярном выражении можно впоследствии обратиться через переменную:
Библиотека PCRE поддерживает именованные выделения, используя следующий синтаксис:
? name > Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0 ?’ name ‘ Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0 ?P name > Python-совместимый синтаксис, поддерживается начиная с PCRE-4.0
Однако такое использование должно ограничиваться простыми случаями как в примере выше, поскольку нумерованные выделения легко могут быть перезаписаны.
Прочие имена
Некоторые имена имеют специальное значение.
Если необходимо обрабатывать запросы без поля “Host” в заголовке в блоке server, который не является сервером по умолчанию, следует указать пустое имя:
Если директива server_name не задана в блоке server, то nginx будет использовать пустое имя в качестве имени сервера.
Версии nginx вплоть до 0.8.48 в этом случае использовали имя хоста (hostname) машины в качестве имени сервера.
Если в запросе вместо имени сервера указан IP-адрес, то поле “Host” заголовка запроса будет содержать IP-адрес, и запрос можно обработать, используя IP-адрес как имя сервера:
В примерах конфигурации серверов, обрабатывающих все запросы, встречается странное имя “ _ ”:
Версии nginx вплоть до 0.6.25 поддерживали специальное имя “ * ”, которое многими неверно воспринималось как имя сервера для обработки всех запросов. Оно никогда так не работало, и не работало как имя с маской. Это имя действовало так же, как сейчас действует директива server_name_in_redirect. Специальное имя “ * ” объявлено устаревшим, а вместо него следует использовать директиву server_name_in_redirect. Заметьте, что с помощью директивы server_name нельзя задать ни имя сервера для обработки всех запросов, ни сервер по умолчанию. Это является свойством директивы listen, а не server_name. См. также “Как nginx обрабатывает запросы”. Можно настроить серверы, слушающие на портах *:80 и *:8080, и указать, что один из них будет сервером по умолчанию для порта *:8080, а другой — для порта *:80:
Интернационализованные имена
Для указания интернационализированных доменных имён (IDNs) в директиве server_name следует указывать Punycode-представление имени:
Выбор виртуального сервера
Сначала соединение создаётся в контесте сервера по умолчанию. Затем имя сервера может быть определено на следующих стадиях обработки запроса, каждая из которых участвует в выборе конфигурации:
предварительно во время операции SSL handshake согласно SNI
после обработки строки запроса
после обработки поля Host заголовка запроса
если после обработки строки запроса или поля Host заголовка запроса имя сервера не было выбрано, то nginx будет использовать пустое имя в качестве имени сервера.
На каждой из этих стадий могут применяться различные конфигурации сервера. Таким образом, некоторые директивы следует указывать с осторожностью:
Оптимизация
Точные имена, имена с масками, начинающиеся со звёздочки, и имена с масками, заканчивающиеся на звёздочку, хранятся в трёх хэш-таблицах, привязанных к слушающим портам. Размеры хэш-таблиц оптимизируются на фазе конфигурации таким образом, что имя может быть найдено с минимальным числом непопаданий в кэш процессора. Подробнее настройка хэш-таблиц обсуждается в отдельном документе.
В первую очередь имя ищется в хэш-таблице точных имён. Если имя не было найдено, то имя ищется в хэш-таблице имён с масками, начинающихся со звёздочки. Если и там поиск не дал результата, то имя ищется в хэш-таблице имён с масками, оканчивающихся на звёздочку.
Регулярные выражения проверяются последовательно, а значит являются самым медленным и плохо масштабируемым методом.
нежели чем использовать упрощённую форму:
Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив server_names_hash_max_size и server_names_hash_bucket_size на уровне http. Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора. Если значение по умолчанию равно 32 и имя сервера задано как “ too.long.server.name.example.org ”, то nginx откажется запускаться и выдаст сообщение об ошибке:
В этом случае следует увеличить значение директивы до следующей степени двойки:
Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:
В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.
Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта). За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.
Что такое name-сервер (NS)
Имя сайта (домен) понятен пользователю, но компьютеру для открытия страниц необходимо знать точный цифровой адрес. Преобразованием «на лету» занимается DNS-сервер (другие наименования – name-сервер, nameserver, NS). Он переводит доменное имя в IP-адрес или наоборот, в зависимости от задачи. В любом случае без этого промежуточного звена открыть веб-ресурс не получится.
Какие функции выполняет name-сервер?
Обычному пользователю и не нужно знать технические детали, NS-серверы работают в прозрачном режиме, их роль незаметна. После ввода имени сайта в адресную строку браузера и нажатия клавиши Enter «сразу» открывается запрошенная страница. Обращение к DNS будет видно только по логу работы приложения.
Часто первое открытие нового веб-ресурса происходит медленно из-за времени, необходимого для ответа DNS-сервера. Последующие запуски происходят быстрее именно благодаря кэшу со списком ранее запрошенных доменов. Технически «промежуточные» узлы делятся по функционалу на три группы:
Сайт не откроется при неправильно указанном адресе DNS-сервера (на хостинге) или при его недоступности, потому что браузер «не будет знать», на каком реальном IP находится сервер, который используется для размещения файлов веб-ресурса. Если владельцу доступна возможность внести правки в настройки хостинга, пользователю остается лишь ждать решения проблемы.
Что такое дочерний NS-сервер?
Практически все хостинг-провайдеры бесплатно предлагают DNS-серверы. И везде работает как минимум один дочерний (резервный) хост. Дочерние серверы формируются при помощи «родительского» домена, например ns1.timeweb.org, ns2.timeweb.org. Такой подход дает возможность размещать их на основном сервере (за счет этого он и предоставляется безвозмездно).
При настройке NS-записей на «родном» хостинге, где покупались домены, достаточно внести имена и сохранить изменения. В большинстве случаев они вводятся автоматически при регистрации сайта (имени). Если же приходится делегировать полномочия другим пользователям, понадобится добавить IP-адреса. Без них работать система идентификации онлайн-ресурсов не будет.
Ресурсные записи для домена
То же относится к настройке электронной почты и других веб-сервисов. Провайдер вносит данные в автоматическом режиме или вручную в панели управления хостингом. Второе чаще востребовано в случае аренды платных DNS-серверов. Например, если у компании одновременно работает сразу несколько сайтов (существуют тарифы до 150 доменов и 12 000 записей).
Базовые типы записей:
От корректности заполнения адресов DNS-сервера зависит работоспособность сайта и его продвижение. Например, MX-записи используются для повышения репутации при рассылках по email (с ними письма реже попадают в категорию «спам»). TXT-записи востребованы для работы системных администраторов и оптимизаторов, пользующихся сторонними сервисами мониторинга и анализа сайтов.
Что такое name-серверы (NS)
DNS-сервер (Name-сервер, nameserver, NS) — сервер, преобразующий доменные имена, с которыми работают пользователи, в понятные компьютерам IP-адреса или в обратном направлении. Обычно не делают разницы между понятиями NS и DNS-серверов.
Какие функции выполняет name-сервер?
Привычные пользователям домены не являются настоящими адресами хостов в сети, для идентификации которых на практике используются IP-адреса. Работа с ними неудобна для пользователей, поэтому применяется система DNS-серверов. Они выполняют несколько базовых функций.
Существует 3 основных типа DNS-серверов:
Что такое дочерние NS-серверы?
Дочерние DNS-серверы настраиваются на основе используемого родительского домена. Например, для example.net дочерние NS будут выглядеть так:
Дочерние DNS-серверы позволяют расположить DNS-серверы для домена на его поддоменах.
При делегировании домена с использованием дочерних DNS-серверов потребуется помимо их имен указать и IP-адреса.
Какие бывают ресурсные записи для домена?
Для того, чтобы настроить на своем домене сайт, почту или другие сервисы, потребуется в зоне домена указать соответствующие сервисам ресурсные записи.
Настройка ресурсных записей выполняется либо хостинг-провайдером автоматически, при создании сайта или почты в панели управления хостингом, либо администратором домена вручную с помощью специального редактора.
Базовые типы записей, с которыми работают администраторы и владельцы сайтов:
Корректность заполнения ресурсных записей важна для успешного делегирования домена и дальнейшего функционирования службы name-серверов. Главное правило оформления NS-записей — не забывать ставить точку после имени. В противном случае возможны ошибки и служба DNS не сможет направить запрос по правильному адресу.
Какие DNS-серверы необходимо указывать для домена?
Список DNS-серверов услуг RU-CENTER вы найдете в статье.
Введение в DNS: основные термины, компоненты и понятия
DNS (или Domain Name System, система доменных имен) – довольно сложная область в управлении серверами и сайтами. Навыки работы с DNS помогут вам определить проблемы в настройках доступа к веб-сайтам и расширят понимание того, что происходит «за кадром».
В этой статье вы найдете основные понятия DNS, которые помогут вам справиться с базовой конфигурацией DNS.
Читайте также:
Основные термины DNS
Для начала нужно разобраться с терминологией. С некоторыми терминами вы знакомы из других областей вычислений, однако в DNS существует много узких терминов, используемых только при работе с доменами и DNS.
Как работает DNS?
Теперь, когда вы знаете основные термины, можно посмотреть, как работает система DNS.
Эта система на первый взгляд довольно проста, но это совсем не так при подробном знакомстве. В целом, однако, это очень надежная инфраструктура, которая необходима для внедрения Интернета.
Корневые серверы DNS
Ранее уже говорилось, что DNS по своей сути является иерархической системой. В верхней части этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и передают полномочия ICANN.
В настоящее время существует 13 корневых серверов. Но поскольку им нужно каждую минуту разрешать огромное количество имен, каждый из этих серверов зеркалируется. Важно знать, что корневой сервер и его зеркала используют один и тот же IP-адрес. Когда определенный корневой сервер получает запрос, он перенаправляется на ближайшее зеркало этого корневого сервера.
Что делают эти корневые серверы? Они обрабатывают запросы на информацию о доменах верхнего уровня. Поэтому, если запрос содержит что-то, что не может разрешить сервер имен нижнего уровня, запрос передается на корневой сервер домена.
Корневые серверы не знают, где находится домен. Тем не менее, они могут направлять инициатора запроса на серверы имен, которые обрабатывают запрошенный домен верхнего уровня.
К примеру, если запрос на www.wikipedia.org отправлен на корневой сервер, корневой сервер не найдет результат в своих записях. Он проверит свои файлы зон и попробует найти запись, которая соответствует «www.wikipedia.org». Но не не найдет ее. Вместо этого он найдет запись для «org» и предоставит запрашивающей организации адрес сервера имен, ответственного за адреса «org».
TLD-серверы
Затем инициатор запроса отправляет новый запрос на предоставленный ему корневым сервером IP-адрес, который отвечает за домен верхнего уровня запроса.
Например, он отправил бы запрос серверу имен, ответственному за домены «org», чтобы узнать, где находится www.wikipedia.org.
Новый сервер также будет искать www.wikipdia.org в своих файлах зон. Он не найдет эту запись в своих файлах, однако он найдет запись с IP-адресом сервера имен, ответственным за «wikipedia.org».
Серверы имен доменов
На этом этапе инициатор запроса имеет IP-адрес сервера имен, который отвечает за IP-адрес ресурса. Он отправляет новый запрос серверу имен, снова спрашивая, может ли он разрешить www.wikipedia.org.
Сервер имен проверяет свои файлы зон и обнаруживает, что у него есть файл зоны, связанный с «wikipedia.org». Внутри этого файла есть запись для хоста «www». Эта запись сообщает IP-адрес, где находится этот хост. Сервер имен возвращает окончательный ответ инициатору запроса.
Что такое разрешающий сервер имен?
В приведенном выше примере упоминается инициатор запроса. Что это такое?
Почти во всех случаях инициатор запроса будет так называемым «разрешающим сервером имен». Разрешающий сервер имен задает вопросы другим серверам. Это, по сути, посредник пользователя, который кэширует предыдущие результаты запроса для повышения скорости и знает адреса корневых серверов, чтобы иметь возможность «разрешать» запросы, о которых он еще не знает.
В принципе, у пользователя обычно есть несколько разрешающих серверов имен. Разрешающие серверы имен обычно предоставляются провайдером или другими организациями. Например, Google предоставляет разрешающие DNS-серверы. Их можно настроить на вашем компьютере автоматически или вручную.
Когда вы вводите URL-адрес в адресной строке браузера, компьютер сначала смотрит, может ли он узнать локально, где находится ресурс. Он проверяет файл hosts и несколько других мест. Затем он отправляет запрос на разрешающий сервер имен и ждет ответа, чтобы получить IP-адрес ресурса.
Затем разрешающий сервер имен проверяет свой кэш. Если он не найдет в кэше ответ, он выполнит описанные выше действия.
Разрешающий сервер имен сокращает процесс запроса для конечного пользователя. Клиенты просто должны спросить у этого сервера, где находится ресурс, и ждать окончательного ответа.
Файлы зон
Файлы зон – это файлы, в которых серверы имен хранят информацию об известных им доменах. Каждый домен, о котором знает сервер имен, хранится в файле зоны. Среднестатистический сервер имеет в своих файлах зон записи для большинства поступающих запросов.
Если он настроен на обработку рекурсивных запросов, он найдет ответ и вернет его. В противном случае он сообщит запрашивающей стороне, где искать дальше.
Чем больше файлов зон имеет сервер имен, тем больше запросов он сможет авторитетно обслужить.
Файл зоны описывает зону DNS, которая представляет подмножество всей системы именования DNS. Он обычно используется для настройки одного домена. Он может содержать несколько записей, которые определяют, где находятся ресурсы данного домена.
$ORIGIN – это параметр, который определяет максимальный авторитет зоны по умолчанию.
Он указывается либо вверху файла зоны, либо в файле конфигурации DNS-сервера, который ссылается на файл зоны. В любом случае этот параметр описывает, для каких доменов зона будет авторитетной.
Типы записей
Файлы зон могут содержать записи разных типов. Рассмотрим самые распространенные из них.
SOA-записи
Начало SOA-записи выглядит примерно так:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
Записи А и АААА
Обе эти записи сопоставляют хост с IP-адресом. Запись A используется для сопоставления хоста с IP-адресом IPv4, а запись AAAA используется для сопоставления хоста с IPv6-адресом.
Общий формат этих записей таков:
host IN A IPv4_address
host IN AAAA IPv6_address
Так как SOA-запись определила ns1.domain.com как основной сервер, его нужно сопоставить с IP-адресом, поскольку ns1.domain.com находится в зоне domain.com.
Запись может выглядеть примерно так:
ns1 IN A 111.222.111.222
ns1.domain.com. IN A 111.222.111.222
В большинстве случаев здесь определяется веб-сервер как www:
www IN A 222.222.222.222
Также нужн указать, куда разрешается базовый домен. Сделать это можно так:
domain.com. IN A 222.222.222.222
Можно использовать @ для ссылки на базовый домен:
Специальный символ * позволяет разрешить все, связанное с этим доменом, что не определено явно на этом сервере.
Аналогичным образом создаются и записи AAAA для адресов IPv6.
CNAME-записи
Записи CNAME определяют псевдоним для канонического имени вашего сервера (которое определяется записью A или AAAA).
Например, если запись A определяет хост server1, вы можете использовать «www» в качестве псевдонима для этого хоста:
server1 IN A 111.111.111.111
www IN CNAME server1
Имейте в виду, эти псевдонимы сказываются на производительности, поскольку они требуют дополнительного запроса к серверу. В большинстве случаев такого же результата можно достичь, используя дополнительные записи A или AAAA.
Одним из случаев, когда рекомендуется использовать CNAME, является создание псевдонима ресурса за пределами текущей зоны.
MX-записи
Записи MX используются для определения почтовых обменов домена. Это помогает правильно отправлять сообщения электронной почты на почтовый сервер.
В отличие от многих других типов записей, почтовые записи, как правило, не привязывают хост, а применяются ко всей зоне. Они обычно выглядят так:
IN MX 10 mail.domain.com.
Обратите внимание, в начале нет имени хоста.
Также стоит отметить, что в записи есть дополнительное число. Оно определяет приоритет сервера и помогает компьютерам решить, на какой сервер отправлять почту, если определено несколько почтовых серверов. Чем ниже это число – тем выше приоритет сервера.
Запись MX обычно указывает на хост, определенный записью A или AAAA, а не на хост CNAME.
Итак, допустим, у вас есть два почтовых сервера. Для этого нужны примерно такие записи:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
В данной настройке хост mail1 имеет более высокий приоритет.
Эти записи можно создать так:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
NS-записи
Этот тип записи определяет серверы имен, которые используются для этой зоны.
Если файл зоны находится на сервере имен, зачем ему нужно ссылаться на этот сервер? Производительность DNS во многом зависит от уровней кэширования. Файл зоны может обслуживаться из кэшированной копии на другом сервере имен. Существуют и другие причины для того, чтобы определять серверы имен на самом сервере имен.
Как и записи MX, эти параметры распространяются на всю зону, поэтому они также не принимают хосты. В целом эти записи выглядят так:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
У вас должно быть как минимум два сервера имен, определенных в каждом файле зоны (чтобы обеспечить корректную работу в случае сбоя одного из серверов). Большинство программ DNS-серверов считают, что файл зоны недействителен, если указан только один сервер имен.
Включите сопоставление хостов с записями A или AAAA:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
PTR-записи
Вот пример записи PTR для 111.222.333.444:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Этот пример записи PTR для IPv6-адреса показывает полубайтовый формат обратного DNS-сервера Google IPv6 2001:4860:4860::8888.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
Вот пример команды dig.
Эта команда вернет домен в записи PTR:
Серверы в Интернете используют записи PTR для размещения доменных имен в записях логов, принятия решений по управлению спамом и отображения сведений о других устройствах в удобочитаемом формате.
Наиболее часто используемые серверы электронной почты будут искать в записи PTR IP-адрес, от которого исходит почта. Если у исходного IP-адреса нет связанной с ним PTR-записи, отправленные сообщения могут рассматриваться как спам и блокироваться. FQDN в PTR-записи не обязательно должен соответствовать доменному имени отправляемого письма. Важно, чтобы у IP-адреса была действительная запись PTR с соответствующей A-записью.
Примечание: Важно, чтобы FQDN в записи PTR имело соответствующую A-запись. Например, адрес 111.222.333.444 имеет PTR-запись для server.example.com, а server.example.com – это запись A, которая указывает на 111.222.333.444.
CAA-записи
Записи CAA используются для определения доверенных центров сертификации (ЦС), которые могут выдавать сертификаты SSL /TLS для вашего домена. По состоянию на 8 сентября 2017 года все ЦС должны проверять эти записи перед выдачей сертификата. Если такой записи нет, любой ЦС может выдать сертификат. В противном случае выдавать сертификаты могут только указанные в записях ЦС. Записи CAA могут применяться к отдельным хостам или целым доменам.
CAA-запись выглядит так:
example.com. IN CAA 0 issue «letsencrypt.org»
Хост, IN и тип записи (CAA) – это обычные поля DNS. Информация, относящаяся к CAA, приведена в разделе «letencrypt.org». Он состоит из трех частей: флаги (0), теги (issue) и значения («letencrypt.org»).
Вы можете использовать dig для извлечения записей CAA, используя следующие параметры:
Что такое name-серверы NS и DNS?
Содержание
Определение DNS
«DNS-клиентами» являются практически все сайты, размещенные в сети Интернет. Всякий раз, когда вы при посещении wap или web-страниц набираете доменное имя, служба DNS серверов должна выяснить, какому IP-адресу соответствует данное имя домена. Именно по этой причине правильное задание DNS-серверов является одной из важнейших настроек для работы wap или web-сайтов в сети Интернет.
Интернет представляет собой самую большую компьютерную сеть. С точки зрения пользователя, каждый узел или ресурс в этой сети идентифицируется уникальным именем – так называемым доменным именем. Некоторыми примерами ресурсов Интернет, для которых определяются доменные имена, являются: Web-серверы; Mail-серверы.
С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется IP-адресом, который представляет собой набор из четырех групп чисел, разделенных точками (например, 123.67.43.245). Для доступа к ресурсам Интернета по доменным именам, понятным пользователям, а не по этим IP-адресам, пользователям нужна система, которая преобразовывает доменные имена в IP-адреса и обратно. Такое преобразование является первоочередной задачей сервисов, называемых Domain Name System (DNS).
Пользователи получают доступ к ресурсам Интернета (например, web-серверу) с помощью соответствующей клиентской программы (например, web-браузера), указывая доменное имя этого ресурса.
Функция DNS, описанная выше, включает следующие составные части. Во-первых, необходимо иметь репозиторий для хранения доменных имен и соответствующих им IP-адресов. Так как количество доменных имен весьма велико, то основными требованиями являются масштабируемость и эффективность. Также должно существовать ПО, которое управляет этим репозиторием и предоставляет функцию разрешения имен. Эти две функции (управление репозиторием доменных имен и предоставление сервиса разрешения имен) выполняются компонентой DNS, называемой name-сервер. Существует несколько категорий таких серверов – рекурсивный name-сервер и stub resolver, различающиеся по своим возможностям. Коммуникационный протокол, различные компоненты DNS, политики, которые определяют конфигурацию этих компонент, процедуры создания, хранения и использования доменных имен составляют инфраструктуру DNS.
Name-сервер
Name-сервер выполняет следующие функции:
Двумя основными компонентами ПО DNS являются name-сервер и resolver. Основные функции name-сервера состоят в обслуживании базы данных (называемой зонным файлом), содержащей информацию о зоне, и в предоставлении ответов на запросы разрешения имени посредством авторитетных ответов. Основной функцией ПО resolver’а является запрос или серия запросов разрешения имени. Основными данными DNS является зонный файл; другим типом данных DNS является конфигурационный файл.
Name-сервер (DNS-сервер, NS-запись) — это сервер, являющийся частью системы DNS. Для парковки домена на хостинг необходимо указывать у регистратора домена значение Primary и Secondary Name-серверов. Для нашего хостинга Name-серверы имеют следующий вид:
Существует два основных типа name-серверов: авторитетные name-серверы и кэширующие name-серверы. Термин авторитетный относится к зоне. Если name-сервер содержит ресурсные записи, касающиеся конкретной зоны, он называется авторитетным name-сервером для данной зоны. Такой сервер предоставляет ответы на запросы разрешения имен для данной зоны, используя ресурсные записи в своем собственном зонном файле. Кэширующий name-сервер, в противоположность предыдущему типу name-сервера, предоставляет ответы посредством серии запросов либо к авторитетным name-серверам, расположенным выше в иерархии доменов, либо из кэша, полученного из ответов на предыдущие запросы.
Resolver’ы
Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.