Dns domain name system так называется серверная программа которая обеспечивает

DNS (Domain Name System, система доменных имён) — система, в которой все доменные имена серверов находятся в определённой иерархии. Для чего она нужна?

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

Так, когда вы вводите в поисковой строке браузера cloud.timeweb.com, данные запроса отправляются на DNS-сервер, который ищет совпадения в своей базе. Затем DNS-сервер посылает на устройство нужный IP-адрес и только тогда браузер обращается непосредственно к ресурсу.

Настройка собственной DNS позволяет более гибко и точно конфигурировать систему и не зависеть от третьих лиц. В этой статье мы рассмотрим, как настроить DNS с помощью сервера имён BIND на Ubuntu.

Термины

Зона — часть иерархии доменных имён, которая размещается на DNS-сервере. Она нужна для того, чтобы установить рамки, в пределах которых распространяется ответственность конкретного сервера или группы серверов.

Система доменных имен DNS | Курс «Компьютерные сети»

Корневые серверы — это DNS-серверы, которые содержат информацию о доменах первого уровня (.ru, .com и так далее).

Доменом называют именованную часть в иерархии DNS. Это определённый узел, который включает в себя другие узлы. DNS-адреса читаются справа налево и начинаются с точки, точкой также отделяются домены.То есть домен cloud.timeweb.com правильно читать так: .com.timeweb.cloud. Чаще всего доменное имя отражает структуру иерархии DNS, но последняя точка опускается.

FQDN — это имя полное имя домена, которое включает в себя имена всех родительских доменов.

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

1. Имя (NAME) — имя или IP-адрес, которому принадлежит зона.
2. Время жизни (Time to Live, TTL) — время хранения записи в кэше DNS, по прошествии которого запись удаляется.
3. Класс (CLASS) — тип сети, чаще всего IN — Internet.
4. Тип (TYPE) — назначение записи
5. Различная информация (DATA)

Самые частые ресурсные записи

A-запись. Имя хоста на адрес IPv4. Для каждого сетевого интерфейса можно сделать только одну A-запись.

timeweb.com. 86400 IN A 185.114.246.105

AAAA-запись. Это то же самое, что А-запись, только справедливо для IPv6.

CNAME. Каноническая запись. Содержит псевдоним реального имени для перенаправления.

ftp 86400 IN CNAME store.cloud.timweb.com.

MX. Указывает хосты для доставки почты, адресованной домену. Поле NAME содержит домен назначения, а поле DATA — приоритет и хост для приёма почты.

website.ru. 17790 IN MX 10 mx.website.ru.
website.ru. 17790 IN MX 20 mx2.website.ru.

NS. Указывает на DNS-сервер, которым обслуживается домен.

DNS сервер — что это и как работает?

PTR. IP-адрес в доменное имя. Необходимо для обратного преобразования имён.

SOA. Описывает основные настройки зоны.

SRV. Содержит адреса серверов, которые обеспечивают работу внутренних служб домена. Например, Jabber.

Инфраструктура

Для того, чтобы следовать всем инструкциям в статье, вам необходимо иметь как минимум два сервера Ubuntu в одном ЦОД. Любой из этих серверов вы можете заказать на cloud.timeweb.com .

Нам понадобится два сервера на Ubuntu 18.04, они будут использоваться в качестве первичного и вторичного DNS-серверов — ns1 и ns2 соответственно. А также дополнительные серверы, которые будут использовать наши настроенные серверы.

Вы должны иметь права суперпользователя на каждом из серверов. Чтобы узнать, как это получить административные доступ, воспользуйтесь статьёй в нашем блоге — Редактирование файла sudoers .

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

В этой статье мы будем использовать bind в качестве DNS-сервера . Установим пакет bind9 из репозитория Linux:

sudo apt update sudo apt upgrade -y
sudo apt install bind9

Кроме этого рекомендуем установить сразу инструменты мониторинга сети:

sudo apt install dnsutils

После установки запускаем службу bind9:

sudo service bind9 start

Основной конфигурационный файл сервера — /etc/bind/named.conf. Он описывает общие настройки и обычно разбивается на несколько других для удобства. С работы с параметрами внутри этого файла начинается настройка DNS .

named.conf.options. Этот файл содержит общие параметры сервера. В нём укажем данные для конфигурации DNS.

options dnssec-validation auto;
auth-nxdomain no;
directory «/var/cache/bind»;
recursion no; # запрещаем рекурсивные запросы на сервер имён

listen-on 172.16.0.0/16;
127.0.0.0/8; >;

forwarders <
172.16.0.1;
8.8.8.8;
>;
>;

Чтобы проверить, что всё внесено верно, нужно воспользоваться одной из утилит демона named — named-checkconf .

sudo named-checkconf

Если всё написано верно, bind-сервер начал работать.

Первичный DNS-сервер

Первичный DNS-сервер — сервер, который хранит главную копию файла данных зоны. Все зоны будем хранить в каталоге /etc/bind/master-zones основного DNS-сервера . Создадим директорию:

sudo mkdir /etc/bind/master-zones

В ней создадим файл для описания зоны:

sudo touch /etc/bind/master-zones/test.example.com.loсal.zone

… и добавим в него SOA-, NS- и A-записи:

После этого необходимо запустить проверку утилитой named-checkzone .

sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.loсal.zone

named.conf.local. Это ещё один файл, который включается в общий конфиг сервера. В нём мы укажем локальные зоны:

zone «test.example.com.» type master;
file «/etc/bind/master-zones/test.example.com.local.zone»;
>;

После того, как пропишем нужные данные, проверим конфиг и перезагрузим bind9 (флаг -z проверяет файлы зон):

sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart
sudo service bind9 status

Настройка представлений

Настройка представлений позволяет гибко управлять разрешением имён из разных подсетей. В файле /etc/bind/named.conf укажем:

include «/etc/bind/named.conf.options»;

acl «local» < 172.16.0.0/16; >;
view «local» include «/etc/bind/named.conf.local»;
match-clients < local; >;
>;

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

Затем нужно заново перезагрузить bind9:

sudo service bind9 restart

После перезагрузки сервера с другого компьютера локальной сети можно запросить наличие у сервера 172.16.0.5 SOA-записи:

На этом этапе настройка основного DNS-сервера завершена. Далее в статье — вторичный сервер, настройка почтового сервера и обратная зона.

Вторичный сервер

Первые шаги абсолютно такие же, что и в случае с первичным сервером — установка bind9 и сетевых утилит.

sudo apt update sudo apt upgrade -y
sudo apt install bind9
sudo apt install dnsutils
sudo service bind9 start

Далее для того, чтобы хранить файлы зон, создадим каталог /etc/bind/slave и снабдим его необходимыми правами:

sudo mkdir slave
sudo chmod g+w slave

Приступаем к настройке зоны на вторичном сервере. В файл /etc/bind/named.conf.local добавляем зону

zone «test.example.com.» type slave;
file «/etc/bind/slave/test.example.com.local.zone»;
masters < 172.16.0.5; >;
>;

… и в основном конфигурационном файле named.conf настраиваем представления

include «/etc/bind/named.conf.options»;
acl «local» < 172.16.0.0/16; >;
view «local» match-clients < local; >;
include «/etc/bind/named.conf.local»;
>;

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

sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart

Если нет ошибок, нужно выполнить трансфер зоны:

sudo rndc retransfer test.example.com

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

Как только настроили сервер и выполнили трансфер зоны, в конфиге named.conf на первичном сервере нужно ограничить передачу адресом вторичного сервера. Для этого в named.conf нужно добавить директиву allow-transfer с указанием IP-адреса вторичного DNS-сервера.

И перезагружаем сервер:

sudo service bind9 restart

Далее все операции будем проводить на первичном сервере.

Добавление MX-записи

В этом примере мы используем mx в качестве имени хоста, поскольку это общепринятое обозначение. Тогда FQDN — mx.test.example.com.

В файл зоны /etc/bind/master-zones/test.example.com.loсal.zone добавляем ресурсные записи почты и обновляем серийный номер.

Проверим синтаксис и перезапустим bind9:

sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.local.zone
sudo service bind9 reload

Обратная зона

Обратная зона DNS — это особая доменная зона, которая предназначена для того, чтобы определять имя узла по его IP адресу. Например, адрес узла 192.168.1.10 в обратной нотации превращается в 10.1.168.192.in-addr.arpa. Благодаря тому, что используется иерархическая модель, можно делегировать управление зоной владельцу диапазона IP-адресов.

По своей сути, PTR-запись определяет домен по адресу, а значит это практически то же самое, что и A-запись. Она используется в основном для проверки почтовых серверов.

Для настройки зоны обратного просмотра создадим новый файл зоны:

sudo nano /etc/bind/master-zones/16.172/in-addr.arpa.zone

и поместим в него следующее содержимое:

$TTL 3600
16.172.in-addr.arpa. IN SOA (
ns.test.example.com.
admin.test.example.com.
2022041202
10800
1200
604800
3600 )
IN NS ns.test.example.com.
IN NS ns2.test.example.com.

3.101.16.172.in-addr.arpa. IN PTR test.example.com.
5.0.16.172.in-addr.arpa. IN PTR ns.test.example.com.
6.0.16.172.in-addr.arpa. IN PTR ns2.test.example.com.
2.101.16.172.in-addr.arpa. IN PTR mail.test.example.com.

Проверим зону и убедимся в корректности конфигурации:

sudo named-checkzone 16.172.in-addr.arpa /etc/bind/master-zones/16.172.in-addr.arpa.zone

Теперь эту зону нужно добавить в конфигурационный файл named.conf :

sudo nano /etc/bind/named.conf.local
zone «16.172.in-addr.arpa.» type master;
file «/etc/bind/master-zones/16.172.in-addr.arpa.zone»;
allow-transfer < 172.16.0.6; >;
>;

После этого проверяем синтаксис и перезагружаем bind9.

Можно приступать к аналогичной настройке на вторичном сервере. В named.conf.local добавьте следующую конфигурацию:

zone «16.172.in-addr.arpa.» <
type slave;
file «/etc/bind/slave/16.172.in-addr.arpa.zone»;
masters < 172.16.0.5; >;
>;

На этом этапе мы завершили работу с локальными доменными зонами. Можно приступать к конфигурации внешней доменной зоны.

Внешняя доменная зона

Во-первых, для того, чтобы запросы из внешней сети обрабатывались нашим сервером нужно в файле конфигурации named.conf.options добавить внешний адрес в директиву listen-on :

.
listen-on aaa.bbb.ccc.ddd/32; # наш внешний IP
172.16.0.0;
127.0.0.0/8
>
…

Далее создадим файл зоны (не забудьте изменить серийный номер!) и добавим в него внешние IP-адреса.

sudo nano /etc/bind/master-zones/test.example.com.zone

Затем создадим для зон внешнего просмотра отдельный файл, чтобы раздавать разные доменные зоны клиентам из разных подсетей.

sudo nano /etc/bind/named.conf.external

И добавим в него следующее содержимое:

zone «test.example.com.» <
type master;
file «/etc/bind/master-zones/test.example.com.zone»;
allow-transfer < 172.16.0.6; >;
>;

После этого подключим файл в named.conf , добавив такой блок:

acl «external-view» aaa.bbb.ccc.ddd; >;
view «external-view» recursion no;
match-clients < external-view; >;
include «/etc/bind/named.conf.external»;
>;

Осталось проверить эту зону и перезагрузить bind9:

sudo named-checkconf -z
sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.zone
sudo service bind9 restart
sudo service bind9 status

На вторичном DNS-сервере в named.conf.options нам нужно указать внешний адрес сервера:

sudo nano /etc/bind/named.conf.options
options dnssec-validation auto;
auth-nxdomain no;
recursion no;
directory «/var/cache/bind»;
listen-on eee.fff.ggg.hhh/24;
172.16.0.0/16;
127.0.0.0/8;
>;
>;

И точно так же, как на первой машине, создаём новый файл named.conf.external:

sudo nano /etc/bind/named.conf.external

Со следующим содержимым:

zone «test.example.com.» type slave;
file «/etc/bind/slave/test.example.com.zone»;
masters < 172.16.0.5; >;
>;

Далее в named.conf добавляем следующий блок:

acl «external-view» eee.fff.ggg.hhh; >;
view «external-view» <
recursion no;
match-clients < external-view; >;
include «/etc/bind/named.conf.external»;
>;

И выполняем трансфер:

sudo rndc retransfer test.example.com IN external-view

Отладка

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

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

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

sudo nano /etc/bind/log.conf

И поместим в него содержимое:

logging channel bind.log file «/var/lib/bind/bind.log» versions 10 size 20m;
severity debug;
print-category yes;
print-severity yes;
print-time yes;
>;
category queries < bind.log; >;
category default < bind.log; >;
category config < bind.log; >;
>;

После этого подключим файл в основной конфиг:

include «/etc/bind/log.conf»

И перезагрузим bind9:

sudo service bind9 restart

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

Заключение

Теперь вы сможете самостоятельно сконфигурировать систему так, чтобы обращаться к реусрсам по имени, а не по IP-адресу. Для этого в качестве примера мы настроили на сервере с OS Ubuntu dns с помощью пакета bind9.

Однако теперь вы должны внимательно следить за основным и вторичным серверами, поскольку они обрабатывают DNS-запросы внутри системы.

Источник: timeweb.cloud

DNS сервер BIND (теория)

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

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

Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

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

На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux.

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

Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

mail.k-max.name. | | | | | | | | | +-корневой домен | | | +—домен первого уровня | | +——точка, разделяющая домены/части FQDN | +———домен второго уровня +—————поддомен/домен третьего уровня, возможно — имя хоста

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др).

Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н.

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

Ресурсные записи

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

Запись ресурса состоит из следующих полей:

k-max.name. 86400 IN A 81.177.139.65
ftp 86400 IN CNAME www.k-max.name.

Источник: habr.com

DNS-сервер: что это и как работает

Чтобы попасть на какой-нибудь сайт, нам нужно знать его доменное имя. Например, вводим edgecenter.ru — и попадаем на главную страницу.

1999 просмотров

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

В этом материале мы постараемся понятно объяснить, что такое DNS и DNS-серверы, для чего всё это нужно и как работает.

• Что такое DNS
• Что такое DNS-сервер
• Зачем нужен DNS-сервер
• Виды DNS-серверов
• Как это работает
• Что такое DNS-зоны
• DNS-хостинг

Что такое DNS

DNS (Domain Name System) — это иерархически распределённая база данных. Одна из её функций — связывать названия доменов с IP-адресами серверов, на которых они располагаются.

У любого сайта есть свой IP-адрес. Сейчас используются два типа адресов:

• IPv4 — четырёхбайтные адреса. Записываются как сочетание 4 чисел от 0 до 255 в формате 000.111.222.123.
• IPv6 — более современный тип, шестнадцатибайтные адреса. Имеют несколько форматов записи. Самый распространённый представляет собой 8 групп по 4 символа (8 четырёхзначных шестнадцатеричных чисел), разделённых двоеточием. Выглядит такой адрес вот так: 1234:abcd:1b4d:000a:987c:5555:a2d8:bcd6.

Эти адреса можно сравнить с телефонными номерами, а доменные имена — с именами людей, которым эти номера телефонов принадлежат. Domain Name System же — это что-то вроде системы поиска контактов в нашем телефоне.

Когда мы хотим попасть на веб-ресурс, например на edgecenter.ru, мы указываем название домена, а система переводит его в IP-адрес и по нему определяет, куда необходимо послать запрос. Запрос уходит по назначению, и в нашем браузере загружается нужная страница.

Что такое DNS-сервер

Если DNS мы сравниваем с системой поиска контактов в смартфоне, то DNS-серверы — это телефонные справочники со списками контактов. На них содержатся сведения о доменах и о том, какой IP-адрес принадлежит каждому.

Зачем нужен DNS-сервер

Есть две основные функции:

• Хранение информации — какой IP-адрес относится к домену.
• Кеширование записей других серверов.

С первой функцией всё просто и понятно. У DNS-сервера есть список имён и относящихся к ним адресов. Когда он получает запрос, он отдаёт нужную информацию.

С кешированием всё немного сложнее. На большинстве серверов не хранится вся информация обо всех именах и IP, существующих в интернете.

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

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

Это и называется кешированием.

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

Чтобы лучше понять, как всё это работает, давайте сначала разберёмся, какие в принципе существуют DNS-серверы.

Виды DNS-серверов

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

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

2. Авторитетные — серверы, на которых непосредственно хранится информация. Они могут содержать IP-адреса конкретных доменов. Могут отвечать за доменную зону, например .ru или .com, — знать адреса всех DNS-серверов каждого домена из этой зоны.

К авторитетным серверам, в частности, относятся корневые. Это вершина иерархии, точка входа в пространство имён привычного нам интернета.

Как это работает

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

2. Если данных в кеше нет, браузер отправляет запрос к локальному серверу интернет-провайдера. Тот ищет запись у себя и, если она обнаруживается, отдаёт требуемый IP-адрес.

3. Если у провайдера нет нужных данных, запрос идёт дальше, на корневой сервер DNS. Он выдаст или нужный IP-адрес (если тот у него есть), или адрес DNS-сервера зоны. В нашем случае с edgecenter.ru это будет сервер зоны .ru. Локальный сервер может сохранить этот адрес у себя в кеше, чтобы в следующий раз не обращаться к корневому серверу.

4. Запрос идёт к серверу зоны, который должен сообщить, где хранится IP-адрес нужного домена. Эту информацию локальный сервер тоже сохраняет в кеше.

5. Дальше запрос отправляется на DNS-сервер домена, у которого точно есть требуемый IP-адрес. Он отправит ответ локальному серверу, а тот снова сохранит данные в кеше, чтобы в следующий раз запросу не пришлось проделывать столь долгий путь.

6. Адрес передаётся браузеру, и тот сможет связаться с хостингом веб-ресурса.

Что такое DNS-зоны

В нашем примере была ситуация, когда есть один домен и ему соответствует один IP-адрес. Но на практике так бывает далеко не всегда.

У одного домена бывает и несколько IP-адресов. А ещё у него могут быть поддомены, у которых тоже часто бывают свои IP-адреса.

Информация о доменах, поддоменах и их IP прописывается в ресурсных записях. Их существует довольно много. Для понимания общей картины мы назовём самые основные:

• A и AAAA — адрес веб-приложения, имеющий конкретное доменное имя.
• MX — имя почтового сервера.
• CNAME — привязывает аналог ресурса к доменному имени; обычно с помощью этой записи привязывают поддомен: например, www.example.com к example.com.
• NS — имя DNS-сервера, ответственного за другие ресурсные записи.
• SOA — начальная запись зоны, которая указывает местоположение эталонной записи о домене; содержит в себе контактную информацию лица, ответственного за данную зону, время кеширования информации на серверах и данные о взаимодействии DNS. Совокупность ресурсных записей домена называется DNS-зоной.

DNS-хостинг

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

Обычно у одного домена бывает несколько таких серверов. Это нужно для безопасности и отказоустойчивости. Если вдруг произойдёт сбой и одна машина выйдет из строя, останутся резервные, и ваш ресурс будет доступен.

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

Но можно выбрать и отдельный DNS-хостинг. И это решение во многих ситуациях будет более выигрышным. И вот почему.

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

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

При выборе такого хостинга нужно учитывать:

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

Источник: vc.ru