Протокол dns описание и принцип работы

Делегирование ответственности

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

Записи серверов имен

Для этого используются dns-записи типа NS (Name Server). Например, за доменную зону yandex.ru отвечают серверы ns1.yandex.ru и ns2.yandex.ru, а за доменную зону urfu.ru отвечает целых 3 сервера. Записи типа ns задаются на домене более высокого уровня в нашем случае на сервере, который отвечает за зону ru. Именно этот сервер содержит записи ns для домена yandex.ru и для домена urfu.ru.

Но нам недостаточно знать только доменные имена dns-серверов, необходимо знать их IP адреса. Для этого используются «приклеенные» записи А, которые указывают IP-адреса. Вся остальная информация о делегированных доменных зонах хранится на этих dns серверах.

Определение имени по IP-адресу

Кроме определения ip адреса по компьютеру, по доменному имени, система dns может использоваться для обратной задачи определения доменного имени компьютера по его IP адресу. Для этого используются специальные зоны, называются обратные (reverse) или реверсивные.

Реверсивная зона содержит записи типа PTR (Pointer), которые ставят в соответствии IP-адрес компьютера доменному имени. Однако из-за технических ограничений DNS не может работать напрямую с IP адресами, поэтому для обратных зон был придуман обходной путь, представлять IP адрес в виде доменного имени. Для этих целей создан специальный домен in-addr.arpa и в этом домене IP адреса записываются в обратном порядке, например адрес 77.88.55.66 в обратной зоне будет записан следующим образом 66.55.88.77.in-addr.arpa.

Адреса сетевых сервисов

Для некоторых типов сервисов интернет, можно указывать не только IP адрес, но и порт на котором этот сервис работает. Для этого используются DNS записи типа SRV (Service record). Структуры этой записи достаточно сложны, вместо доменного имени указывается строка с описанием сервисов в специальном формате (_сервис._протокол.имя.-˃ приоритет вес порт имя).

Например, если мы хотим узнать на каком компьютере и на каком порту работает jabber сервер работающий по протоколу tcp в домене example.com мы получим вот такую запись (0 5 5269 xmpp.example.com). Проще всего разбирать её с конца. Сервис работает на компьютере с доменным именем xmpp.example.com порт 5269, приоритет 0, вес 5. Так же как и с почтовыми серверами, чем меньше значение приоритета, тем более высокий приоритет у сервера.

Резервный jabber сервер для этого домена работает на компьютере backup_xmpp.xample.com порт 5269 приоритет 20, вес 0. Вес используются для распределения нагрузки между разными серверами, которые имеют один и тот же приоритет.

Первый способ

Если домен находится на обслуживании в компании REG.RU, вы можете воспользоваться бесплатными DNS-серверами: ns1.reg.ru и ns2.reg.ru:

1. 1.
   Авторизуйтесь на сайте REG.RU, перейдите в раздел и кликните на имя домена.
2. 2.
   В блоке «Управление» выберите пункт DNS-серверы и управление зоной.
3. 3.
   Выберите пункт Добавить запись. Для привязки домена в поле «Subdomain» впишите @, в поле «IP Address» впишите IP-адрес сервера. Для привязки домена с префиксом www в поле «Subdomain» впишите www, а в поле «IP Address» впишите IP-адрес сервера.

Другой регистратор

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

CNAME-запись

CNAME (canonical name) — это запись, которая отвечает за привязку поддоменов (например, www.site.ru) к каноническому имени домена (site.ru) или другому домену. CNAME-запись дублирует ресурсные записи домена (A, MX, TXT) для поддоменов.

Важно: для одного и того же поддомена нельзя одновременно добавить CNAME-запись и A-запись

Как добавить запись CNAME

Выполните шаги 1-6 инструкции выше.

Затем в поле Субдомен укажите поддомен, кроме @ (для вашего основного домена этот тип записи недоступен, вы можете воспользоваться A-записью);

В поле Значение — Canonical name — домен, на который должен ссылаться поддомен из поля «Subdomain».

Нажмите Сохранить:

Готово, ресурсная запись добавлена в зону домена.

Изменения вступят в силу в течение часа.

Зачем прописывать DNS-серверы для домена

Допустим, вы зарегистрировали домен. Пока никто, кроме вас, об этом не знает. Чтобы о существовании вашего домена узнал Интернет, нужно выбрать и прописать для домена DNS-серверы. Они-то и расскажут другим DNS-серверам Интернета о вашем домене. Так что запоминаем: зарегистрировал домен — пропиши DNS-серверы!

Прописывают DNS-серверы чаще всего парами. Один из DNS является первичным, а остальные серверы, которых может быть от 1 до 12 для каждого домена, называются вторичными. Это делается для лучшей отказоустойчивости: если выйдет из строя первичный DNS-сервер, домен и сайт продолжат свою работу благодаря вторичным.

Рекурсивное разрешение имен

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

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

Разрешение имен с помощью корневых ссылок

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

В этом примере происходят следующие события:

1. Клиент отправляет рекурсивный запрос на DNS-сервер для запроса IP-адреса, соответствующего имени ftp.contoso.com. Рекурсивный запрос указывает, что клиент хочет получить окончательный ответ на запрос. Ответ на рекурсивный запрос должен быть допустимым адресом или сообщением, указывающим, что адрес не найден.
2. Так как DNS-сервер не является полномочным для имени и не имеет ответа в своем кэше, DNS-сервер использует корневые ссылки для поиска IP-адреса корневого сервера DNS.
3. DNS-сервер использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com. Итеративный запрос указывает, что сервер будет принимать ссылку на другой сервер вместо определенного ответа на запрос. Так как имя ftp.contoso.com заканчивается на метку com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.
4. DNS-сервер использует итеративный запрос, чтобы запросить у COM-сервера разрешение имени ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.
5. DNS-сервер использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com. Сервер Contoso находит ответ в данных зоны, а затем возвращает ответ на сервер.
6. Затем сервер возвращает результат клиенту.

Разрешение имен с помощью пересылки

Пересылка позволяет маршрутизировать разрешение имен через определенные серверы вместо использования корневых ссылок. На следующем рисунке показано, как DNS разрешает имя с помощью пересылки.

В этом примере происходят следующие события:

1. Клиент запрашивает DNS-сервер для имени ftp.contoso.com.
2. DNS-сервер перенаправляет запрос на другой DNS-сервер, который называется сервером пересылки.
3. Поскольку сервер пересылки не является полномочным для имени и не имеет ответа в своем кэше, он использует корневые ссылки для поиска IP-адреса корневого сервера DNS.
4. Сервер пересылки использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.
5. Сервер пересылки использует итеративный запрос, попросив серверу com разрешить имя ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.
6. Сервер пересылки использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com. Сервер Contoso находит ответ в файлах зоны, а затем возвращает ответ на сервер.
7. Затем сервер пересылки возвращает результат исходному DNS-серверу.
8. Затем исходный DNS-сервер возвращает результат клиенту.

Как добавить домен на выделенный сервер (Dedicated)

Управление зоной домена происходит на DNS-серверах, указанных для него. Вы можете посмотреть DNS-серверы вашего домена, воспользовавшись инструкцией Как узнать, какие DNS-серверы прописаны для домена.

Если домен был добавлен в панели управления ISPmanager 5

В этом случае управление зоной домена происходит в ISPmanager: откройте панель управления — и перейдите в раздел Доменные имена. Затем нажмите кнопку Записи. Там вы сможете создавать, редактировать и удалять ресурсные записи для домена:

Если домен был добавлен в панели DNSadmin

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

Управление ресурсными записями происходит в разделе Доменные имена — Записи:

Если домен был добавлен в панели DNSmanager

Это два сервера: https://ns5.hosting.reg.ru и https://ns6.hosting.reg.ru. Через них управлять зоной можно только в том случае, если домен был добавлен как «master» (Dedicated выступает в качестве вторичного DNS):

Если кликнуть на Записи, вы попадёте на страницу редактирования записей домена:

Если же домен был добавлен как «slave», то это означает, что Dedicated выступает в качестве первичного DNS, и редактировать зону необходимо непосредственно на нём.

Вы не помните, как привязывали домен к Dedicated

Если вы не помните, где именно добавляли домен, то просто проверьте поочерёдно:

панель управления DNSmanager. Войдите в неё, используя логин и пароль для доступа к DNS:

Устаревшие типы записей

Прогресс сделал некоторые из первоначально определенных типов записей устаревшими. Некоторые из записей, перечисленных в IANA, имеют ограниченное использование по разным причинам. Некоторые из них отмечены в списке как устаревшие, некоторые предназначены для очень малоизвестных служб, некоторые — для более старых версий служб, а некоторые имеют специальные примечания, в которых говорится, что они «неправильные».

Тип	Введите идентификатор. (десятичный)	Определение RFC	Устарело	Описание
Доктор медицины	3	RFC 883	RFC 973	Записи получателя почты (MD) и пересылки почты (MF); MAILA — это не фактический тип записи, а тип запроса, который возвращает записи MF и / или MD. RFC 973 заменил эти записи записью MX.
MF	4
MAILA	254
МБ	7	RFC 883	Формально не устарел. Маловероятно, что когда-либо будет принято (RFC 2505).	MB, MG, MR и MINFO — это записи для публикации списков рассылки подписчиков. MAILB — это код запроса, который возвращает одну из этих записей. MB и MG намеревались заменить команды SMTP VRFY и EXPN. MR должен был заменить ошибку SMTP «551 пользователь не локальный». Позже RFC 2505 рекомендовал отключить и VRFY, и EXPN, сделав MB и MG ненужными. Они были классифицированы как экспериментальные согласно RFC 1035.
MG	8
МИСТЕР	9
МИНФО	14
ПОЧТА	253
WKS	11	RFC 883, RFC 1035	Заявлено как «не заслуживающее доверия» RFC 1123 (подробнее в RFC 1127).	Запись для описания общеизвестных сервисов, поддерживаемых хостом. На практике не используется. Текущая рекомендация и практика заключаются в том, чтобы определить, поддерживается ли услуга на IP-адресе, путем попытки подключиться к нему. SMTP даже запрещено использовать записи WKS при обработке MX.
NB	32	RFC 1002		Ошибки (из RFC 1002); теперь номера присвоены NIMLOC и SRV.
NBSTAT	33
НУЛЕВОЙ	10	RFC 883	RFC 1035	Устарело в соответствии с RFC 1035. RFC 883 определил «запросы завершения» (код операции 2 и, возможно, 3), которые использовали эту запись. RFC 1035 позже переназначил код операции 2 на «статус» и зарезервированный код операции 3.
A6	38	RFC 2874	RFC 6563	Определен как часть раннего IPv6, но переведен на экспериментальный в RFC 3363; позже был понижен до исторического уровня в соответствии с RFC 6563.
NXT	30	RFC 2065	RFC 3755	Часть первой версии DNSSEC (RFC 2065). NXT устарел в результате обновлений DNSSEC (RFC 3755). В то же время область применимости KEY и SIG также была ограничена, чтобы не включать использование DNSSEC.
КЛЮЧ	25
SIG	24
HINFO	13	RFC 883	Не является устаревшим в соответствии с RFC 8482. В настоящее время используется Cloudflare в ответ на запросы типа ANY.	Запись предназначена для предоставления информации о типе центрального процессора и операционной системе. Он был предназначен для того, чтобы протоколы могли оптимизировать обработку при взаимодействии с аналогичными узлами.
RP	17	RFC 1183		RP может использоваться для определенной удобочитаемой информации, касающейся другой точки контакта для конкретного хоста, подсети или другой метки уровня домена, отличной от той, которая используется в записи SOA.
X25	19		Не используется в настоящее время какими-либо заметными приложениями
ISDN	20		Не используется в настоящее время какими-либо заметными приложениями
RT	21 год		Не используется в настоящее время какими-либо заметными приложениями
NSAP	22	RFC 1706		Не используется в настоящее время какими-либо заметными приложениями
NSAP-PTR	23		Не используется в настоящее время какими-либо заметными приложениями
PX	26 год	RFC 2163		Не используется в настоящее время какими-либо заметными приложениями
EID	31 год	N / A
НИМЛОК	32	N / A
ATMA	34	N / A		Определено Комитетом Форума ОрВД.
APL	42	RFC 3123		Задайте списки диапазонов адресов, например, в формате CIDR для различных семейств адресов. Экспериментальный.
РАКОВИНА	40	N / A
GPOS	27	RFC 1712		Более ограниченная ранняя версия записи LOC
УИНФО	100	N / A
UID	101	N / A
GID	102	N / A
UNSPEC	103	N / A
SPF	99	RFC 4408	RFC 7208	Указывается как часть протокола Sender Policy Framework в качестве альтернативы хранению данных SPF в записях TXT с использованием того же формата. Его поддержка была прекращена в RFC 7208 из-за повсеместного отсутствия поддержки.
НИНФО	56	N / A		Используется для предоставления информации о состоянии зоны. Запрошен для проекта IETF «Запись ресурса DNS статуса зоны (ZS)» в 2008 г. Срок действия истек без принятия.
RKEY	57 год	N / A		Используется для шифрования записей NAPTR. Запрошен для проекта IETF «Запись ресурса DNS RKEY» в 2008 году. Срок действия истек без принятия.
ТАЛИНК	58	N / A
NID	104	RFC 6742		Не используется ни одним из известных приложений и отмечен как «экспериментальный»
L32	105
L64	106
LP	107
DOA	259	N / A

Часто используемые DNS-записи

SOA-запись (Start of authority)
SOA-запись DNS определяет авторитетную информацию о доменном имени и зоне в целом.

A-запись (Address)
Эта запись указывает имя хоста и адрес IP определенного компьютера. По сути, любая система с подключением http/https должна иметь свою A-запись, чтобы по доменному имени определялся привязанный к нему IP-адрес.

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

CNAME-запись (Name Alias)
Позволяет создавать отсылки к ранее созданным A-записям и PTR-записям. Чаще всего используется для того, чтобы тот же сайт был доступен под разными доменными именами, например, при создании «зеркал». Запись CNAME позволяет компьютеру иметь более чем одно имя хоста.

MX-запись (Mail Server)
DNS MX-запись сообщает различным почтовым программам о том, где находится нужный почтовый сервер. Без нее предназначенная для указанного домена почта не будет отправлена на IP-адрес из A-записи.

TXT-запись (Text)
Применяется для добавления комментария к выбранному домену. Иначе, чем как добавить TXT-запись в DNS (при его изменении), вы не сможете привязать текст произвольного содержания к домену.

SPF (Sender Policy Framework)
указывает сервера, которые могут отправлять почту от имени домена. Запись SPF вносят в TXT-запись домена.
Пример:

• v=spf1 — определяет версию используемой записи SPF;
• a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной записи домена. Проще говоря с сервера, где размещен сайт;
• mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
• ip4:11.11.11.11 — разрешает приём почты с IP-адреса 11.11.11.11;
• ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также можно использовать:
• -all— отвергать
• +all— пропускать
• ?all— нейтральный режим.

PTR-запись (Reverse Address)
Связывает домен хоста с его IP в обратной зоне DNS, поэтому должен быть прописан для каждого хоста отдельно. Зачастую эта запись создается автоматически, но проверка никогда не помешает. При этом сама же обратная зона DNS допускает использование только трех типов записи — PTR, NS и CNAME.

CAA-запись(Certification Authority Restriction)
С помощью данной записи владелец домена указывает удостоверяющий центр, имеющий право выпускать SSL/TLS-сертификаты для указанного домена. Запись CAA в DNS позволяет избежать несанкционированной выдачи сертификата, что делается либо случайно, либо с целью фишинга или каких-либо другой атаки.

Зоны DNS

Зона DNS используется для размещения DNS-записей определенного домена. Чтобы разместить свой домен в Azure DNS, необходимо создать зону DNS для этого доменного имени. Каждая запись DNS для вашего домена создается внутри этой зоны DNS.

Например, домен contoso.com может содержать несколько записей DNS, включая mail.contoso.com (для почтового сервера) и www.contoso.com (для веб-сайта).

При создании зоны DNS в Azure DNS учитывайте следующее.

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

Примечание

Для создания зоны DNS с доменным именем в Azure DNS необязательно быть его владельцем. Однако, чтобы настроить серверы доменных имен Azure DNS в качестве правильных серверов для доменного имени с помощью регистратора доменных имен, необходимо быть владельцем домена.

Дополнительные сведения см. в статье Делегирование домена в Azure DNS.

Теги Etag

Предположим, что два человека или два процесса пробуют изменить запись DNS одновременно. У какого из них это получится? И будет ли этот человек или процесс знать, что они заменили изменения кого-то другого?

Служба Azure DNS использует теги Etag для безопасной обработки параллельных изменений одного ресурса. Теги ETag не связаны с . С каждым ресурсом DNS (зоной или набором записей) связан Etag. При извлечении ресурса также передается его значение Etag. При обновлении ресурса вы можете вернуть Etag, чтобы служба Azure DNS могла сопоставить его с Etag на сервере. Так как каждое обновление ресурса приводит к повторному созданию Etag, несовпадение Etag указывает на параллельное изменение. Теги Etag можно также использовать при создании ресурса для проверки того, что ресурс не существует.

По умолчанию PowerShell для Azure DNS использует теги Etag для блокировки одновременных изменений зон и наборов записей. С помощью необязательного параметра -Overwrite можно отключить проверки тегов Etag. В этом случае все одновременные изменения перезаписываются.

На уровне API REST службы Azure DNS теги Etag указываются с помощью заголовков HTTP. Их поведение описывается в следующей таблице:

Заголовок	Поведение
None	PUT всегда завершается успешно (без проверки Etag)
If-match <etag>	PUT завершается успешно, только если ресурс существует и Etag соответствует
If-match *	PUT завершается успешно, только если ресурс существует
If-none-match*	PUT завершается успешно, только если ресурс не существует

Режим работы DNS

Серверы DNS могут работать в двух режимах:

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

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

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

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

Сервер разрешения имен DNS

Сервер разрешения имен находится в локальной сети, он предоставляется либо вашим провайдером, либо вашей организации. Часто адреса таких серверов компьютеры получают автоматически, вместе с ip- адресом по протоколу DHCP.

Другой вариант это использовать открытый сервер разрешения имен, которые предоставляют некоторые компании. Например, широко известен общедоступный DNS сервер компании Google с адресом 8.8.8.8, который может использовать кто угодно. Зачем может понадобиться использовать открытый сервер, вместо серверов вашей локальной сети? Некоторые такие серверы, например, сервер компании Яндекс с таким адресом 77.88.8.7 блокирует контент для взрослых.

Кэширование

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

Иногда, это время может составлять несколько дней или даже недель в зависимости от настроек DNS resolver. Поэтому не удивляйтесь, если вы внесли изменения в DNS записи, но они пока не видны.

Типы ответов DNS

В DNS есть два типа ответов:

• Авторитетный или как пишется в утилите nslookup windows —  authoritative «заслуживающий доверие», это ответ, который получен от DNS сервера, который ответственный за данную зону. Ответ получен из конфигурационных файлов на диске сервера, и точно является актуальным.
• Неавторитетный (non-authoritative) или «не заслуживающий доверия ответ», это ответ который получен от сервера, который не является ответственным за эту зону. Как правило, это DNS resolver, который закэшировал полученный ранее ответ. С момента создания записи в кэше данные могли измениться, поэтому ответ называется не заслуживающим доверия, но как правило в кэше находятся верные данные.

Пример реальных записей DNS

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

Вывод состоит из нескольких частей:

• Шапка
• Секция запроса
• Секция ответа
• Служебная информация

Шапка запроса

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

Секция запроса

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

Секция ответа

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

Как запись A, так и AAAA-запись указывают на IP-адрес, который привязан к нашему домену. A-запись указывает IP в формате IPv4, а запись AAAA — в формате IPv6.

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

Запись SOA (Start of Authority) указывает на несколько различных параметров:

1. Сервер с эталонной информацией о текущем домене
2. Контактную информацию ответственного лица
3. Различные параметры кеширования записей

Бывают и некоторые более специфичные ресурсные записи, о которых здесь не было речи, но это не значит, что они бесполезны. Полный перечень таких записей всегда можно найти в документации (например по DNS-серверу BIND).

Что такое DNS

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

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

Как работают DNS-серверы (для любознательных)

Итак, вы вводите название сайта в адресную строку и нажимаете Enter. В те самые секунды, перед тем как сайт отобразится на вашем экране, DNS-серверы работают, не щадя себя. Посмотрим, что делают DNS-серверы. Следите за стрелочками.

DNS переводит имя домена в IP-адрес: как это работает

1. 1.
   Когда вы вводите в строке браузера доменное имя, например, FAQ-REG.RU, браузер ищет на вашем локальном компьютере файл hosts. В нём задаётся соответствие домена IP-адресу. Допустим, в этом файлe есть запись для введённого домена. Что это значит? Что сайт откроется сразу (стрелка 9). Если же записи нет, браузер сформирует DNS-запрос к интернет-провайдеру (стрелка 1), чтобы тот нашёл IP-адрес домена.
2. 2.
   У каждого интернет-провайдера есть локальные (кеширующие) DNS-серверы. После получения запроса провайдер ищет в своём кеше запись о соответствии требуемого домена IP-адресу. Если такая запись есть, браузер получит IP-адрес (стрелка 8). По этому адресу браузер обратится к хостингу, на котором расположен сайт, и пользователю откроется нужная страница (стрелка 9). Если запись отсутствует, провайдер перенаправит DNS-запрос на корневые DNS-серверы (стрелка 2).
3. 3.
   Корневые DNS-серверы хранят информацию только о DNS-серверах, ответственных за доменные зоны. Корневой DNS-сервер не может предоставить провайдеру информацию об IP-адресе домена FAQ-REG.RU. Зато он отправит IP-адрес DNS-сервера доменной зоны, в данном случае зоны .RU (стрелка 3).
4. 4.
   Теперь у интернет-провайдера есть IP-адрес DNS сервера доменной зоны .RU. Поэтому он обращается к этому DNS-серверу и запрашивает IP-адрес домена (стрелка 4).
5. 5.
   DNS-серверы зоны .RU хранят только информацию о DNS-серверах всех доменов в этой зоне, а не их IP-адреса. Поэтому DNS-серверы зоны подскажут Интернет-провайдеру IP-адрес DNS-сервера домена FAQ-REG.RU (стрелка 5).
6. 6.
   Интернет-провайдер получил IP-адрес DNS-сервера домена FAQ-REG.RU. Он обращается к DNS-серверу домена (например, к ns1.hosting.reg.ru) с запросом IP-адреса домена (стрелка 6).
7. 7.
   После получения запроса DNS-сервер сначала проверяет, есть ли у него информация о домене FAQ-REG.RU и искомый IP-адрес для него. В случае успеха DNS-сервер отправит IP-адрес домена интернет-провайдеру (стрелка 7).
8. 8.
   Интернет-провайдер получает IP-адрес домена и сохраняет его у себя в кеше. После этого он отправит браузеру результат DNS-запроса — IP-адрес домена FAQ-REG.RU (стрелка 8).
9. 9.
   Браузер обращается к хостингу по полученному IP-адресу (стрелка 9). Теперь пользователю открывается запрашиваемый сайт FAQ-REG.RU.