Ns запись dns: Что такое name-серверы (NS) — RU-CENTER

Что такое name-серверы (NS) — RU-CENTER

DNS-сервер (Name-сервер, nameserver, NS) — сервер, преобразующий доменные имена, с которыми работают пользователи, в понятные компьютерам IP-адреса или в обратном направлении. Обычно не делают разницы между понятиями NS и DNS-серверов.

• Какие функции выполняет name-сервер?
• Что такое дочерние NS-серверы?
• Какие бывают ресурсные записи для домена?
• Какие DNS-серверы необходимо указывать для домена?

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

1. Преобразуют введенное в адресную строку доменное имя в IP-адрес или наоборот (обратное преобразование).
2. Сообщают об ошибках, если запросы направлены к несуществующей адресам.
3. Предоставляют информацию о сервере, отвечающем за дочернюю зону (поддомены).
4. Кэшируют записи, полученные с других name-серверов. Кэширование помогает увеличить скорость доступа к сайтам. Запросы к удаленному DNS-серверу занимают много времени, поэтому DNS-сервер провайдера хранит адреса ранее запрошенных сайтов в кэше.

Существует 3 основных типа DNS-серверов:

1. Первичный (Primary, master), хранит файл зоны домена с информацией о всех ресурсных записях.
2. Вторичный (Secondary, slave), загружает и хранит копию файла зоны с первичного DNS-сервера. Используется для повышения отказоустойчивости службы DNS.
3. Кэширующий. Предназначен только для кэширования, применяется для разгрузки первичных и вторичных серверов, а также для повышения скорости доступа к сайтам.

Дочерние DNS-серверы настраиваются на основе используемого родительского домена. Например, для example.net дочерние NS будут выглядеть так:

ns1.example.net
ns2.example.net

или:

primary.example.net
secondary.example.net

Дочерние DNS-серверы позволяют расположить DNS-серверы для домена на его поддоменах.

При делегировании домена с использованием дочерних DNS-серверов потребуется помимо их имен указать и IP-адреса.

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

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

Базовые типы записей, с которыми работают администраторы и владельцы сайтов:

• NS-запись — главный тип, определяющий адреса DNS-серверов, обслуживающих домен.
• A-запись — привязывает доменное имя на один IP-адрес, используя протокол IPv4. Возможно использование более одного IP-адреса. Тогда добавляют вторую A-запись c другим IP-адресом. Если есть необходимость указания нескольких имен для одного IP, как правило, используют CNAME-запись для формирования псевдонимов (алиасов).
• AAAA — тип записи, аналогичный предыдущей, но с IPv6-адресами.
• CNAME — указывает, что данный домен выполняет функции псевдонима (алиаса) другого домена. Для псевдонима записи других типов не вносятся.
• MX-запись — указывает имя сервера, ответственного за прием почты для домена. В зоне домена может быть несколько MX-записей с разными приоритетами.
• TXT-запись — используется для хранения произвольной информации в DNS. Запись может использоваться для подтверждения владения доменом в р различных сервисах.
• SOA-запись — содержит служебную информацию: доменное имя, время последнего обновления зоны домена, адрес администратора зоны, настройки временных параметров и другую информацию.

Корректность заполнения ресурсных записей важна для успешного делегирования домена и дальнейшего функционирования службы name-серверов. Главное правило оформления NS-записей — не забывать ставить точку после имени. В противном случае возможны ошибки и служба DNS не сможет направить запрос по правильному адресу.

Список DNS-серверов услуг RU-CENTER вы найдете в статье. 

Что такое ресурсные записи DNS

DNS (система доменных имен) – это «телефонная книга» Интернета. В качестве номера телефона в ней выступает IP-адрес, а в качестве наименований контактов — домены. В такую книгу можно внести не только «телефонный номер», но и дополнительную информацию о контакте («е-mail», «место работы» и т. п.).

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

Информация о домене хранится на DNS-серверах. Чтобы внести её в систему DNS, нужно прописать ресурсные записи. С их помощью серверы делятся сведениями о доменах с другими серверами. Пока не прописаны ресурсные записи для домена, его нет в «телефонной книге» Интернета. Следовательно, работа сайта или почты на нём невозможна. Прежде чем приступать к указанию ресурсных записей, нужно делегировать домен, то есть прописать для него DNS-серверы. Вы можете сделать это по инструкции: Как прописать DNS-серверы для домена в Личном кабинете. Затем переходите к ресурсным записям. Изменения вступят в силу после обновления DNS-серверов (обычно до 24 часов).

Основные ресурсные записи: записи типа A, CNAME, MX, TXT и SPF. С общей информацией по добавлению ресурсных записей вы можете познакомиться в статье: Настройка ресурсных записей в Личном кабинете.

Запись A

Запись A (address) — одна из ключевых ресурсных записей Интернета. Она нужна для связи домена с IP-адресом сервера. Пока не прописана А-запись, ваш сайт не будет работать.
Когда вы вводите название сайта в адресную строку браузера, именно по А-записи DNS определяет, с какого сервера нужно открывать ваш сайт.

Примеры записи A:

где 123.123.123.123 — IP-адрес нужного вам сервера.

Запись CNAME

CNAME (Canonical name) — запись, которая отвечает за привязку поддоменов (например, www.site.ru) к каноническому имени домена (site.ru) или другому домену.
Основная функция CNAME — дублирование ресурсных записей домена (A, MX, TXT) для различных поддоменов.

Примеры записи CNAME:

Имя записи	Тип записи	Значение
www. site.ru	CNAME	site.ru
mail.site.ru	CNAME	webmail.hosting.reg.ru

Если вы пропишете CNAME для поддомена www.site.ru и укажете значение site.ru, сайт будет открываться с того же IP-адреса, что и site.ru. Если вы пропишете CNAME для mail.site.ru и укажете значение webmail.hosting.reg.ru, то на mail.site.ru будут распространятся те же ресурсные записи, что для webmail.hosting.reg.ru.

Важно

Использование записи CNAME исключает использование других ресурсных записей для данного поддомена, то есть для поддомена

Запись MX

MX-запись что это? Это запись, отвечающая за сервер, через который будет работать почта. Записи MX критически важны для работы почты. Благодаря им отправляющая сторона «понимает», на какой сервер нужно отправлять почту для вашего домена.

Примеры записи MX:

где mx1.hosting.reg.ru — нужный вам почтовый сервер.

Обычно указывается два почтовых сервера, чтобы в случае недоступности одного из них почта всё же была отправлена на другой. Приоритет записи определяет, на какой сервер нужно отправлять почту в первую очередь. Чем меньше число, тем выше приоритет. Таким образом, для доменного имени site.ru почтовый сервер mx1.hosting.reg.ru является основным, а mx2.hosting.reg.ru выступает второстепенным. Если приоритет одинаковый, сервер выбирается случайным образом.

Запись TXT

TXT (Text string) — запись, которая содержит любую текстовую информацию о домене. Записи TXT используются для различных целей: подтверждения права собственности на домен, обеспечения безопасности электронной почты, а также подтверждения SSL-сертификата. Часто применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также как контейнер для записи SPF и ключа DKIM. Можно прописывать неограниченное количество TXT-записей, если они не конфликтуют друг с другом.

Запись SPF

SPF-запись (Sender Policy Framework) содержит информацию о списке серверов, которые имеют право отправлять письма от имени заданного домена. Позволяет избежать несанкционированного использования. Настройка SPF прописывается в TXT-записи для домена.

Пример записи SPF:

где 123.123.123.123 — IP-адрес нужного вам сервера.

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

• v=spf1 — определяет версию используемой записи SPF;
• include:_spf.hosting.reg.ru — включает в запись SPF значение SPF-записи другого домена.
  То есть для домена будут действовать все значения записи SPF для домена «_spf.hosting.reg.ru»;
• ip4:123.123.123.123 — разрешает приём почты с IP-адреса 123.123.123.123;
• a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A-записи домена. Проще говоря, с сервера, где размещён сайт;
• mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
• ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также иногда используется -all — в этом случае письмо не проходит дополнительных проверок и сразу отвергается.

Помимо «~» и «-», для параметра «all» существуют ещё ключи:

• «+» — принимать почту,
• «?» — воспринимать письмо нейтрально.

Записи NS, PTR, SOA являются служебными и, как правило, настраиваются автоматически.

Запись NS

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

Запись PTR

PTR — обратная DNS-запись, которая связывает IP-адрес сервера с его каноническим именем (доменом). PTR-запись применяется для фильтрации почты. Для всех серверов виртуального хостинга REG.RU обратные DNS-записи прописываются автоматически. Если у вас заказан VPS или Dedicated-сервер, прописать PTR-запись можно по инструкции: Как настроить PTR-запись?

Запись SOA

SOA (Start of Authority) — начальная запись зоны, которая указывает, на каком сервере хранится эталонная информация о доменном имени. Критически важна для работы службы DNS. Подробнее о том, что такое SOA-запись и как её проверить, вы можете узнать в статье.

Помогла ли вам статья?

Да

101 раз уже помогла

— запись DNS A и NS

спросил 11 лет, 9 месяцев назад

Изменено 5 лет, 6 месяцев назад

Просмотрено 109 тысяч раз

Я пытаюсь немного лучше понять DNS, но все равно не получаю полностью записи A и NS.

Насколько я понял, запись А говорит, какой IP-адрес принадлежит (суб)домену, пока мне это было еще понятно. Но, как я понял, запись NS сообщает, какие точки сервера имен принадлежат (под)домену, и этот сервер имен должен сообщать, какой IP-адрес принадлежит (под)домену. Но это уже было указано в записи A в том же файле DNS. Так может кто-нибудь объяснить мне, что именно делают NS-записи и серверы имен, потому что, вероятно, я что-то не так понял.

edit: Насколько я вас правильно понимаю, запись NS сообщает, что вы должны найти DNS-сервер с записью A для определенного домена, а запись A сообщает вам, какой ip-адрес принадлежит домену. Но какой смысл помещать записи A и NS в один и тот же файл DNS? Если для определенного домена уже есть запись A, то зачем вам указывать на другой DNS-сервер, который, вероятно, даст вам ту же информацию?

• система доменных имен
• сервер имен

1

Несколько примеров из вымышленного файла зоны foo. com

 ....... Запись SOA и многое другое .......
 foo.com. В НС ns1.bar.com.
 foo.com. В А 192.168.100.1
 ....... Еще A/CNAME/AAAA/и т.д. записи .......
 

A Record = «Хост с именем foo.com находится по адресу 192.168.100.1″
NS Record = «Если вы хотите узнать о хостах в 0025 foo.com зона, спросите имя сервера ns1.bar.com»

6

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

• Записи NS на вершине не определяют направление. Вместо этого они дают авторитетное определение тем НС записей.
• Любые записи NS ниже вершины до определяют направление. Эта запись NS не считается достоверной, равно как и запись A с тем же именем.

Из этих правил мы можем вывести два разных поведения, которые происходят, когда Запись существует на DNS-сервере с таким же именем:

• Если запись NS не определяет ссылку, могут существовать другие данные. рядом с ним в той же зоне. Поскольку сервер считает себя авторитетным как для NS и запись A , конфликта нет. Вот почему другие данные обычно находятся рядом с записями NS в вершине зоны.
• Если запись NS определяет ссылку , то запись A эффективно «маскируется» вырезкой зоны. Эта запись A не является авторитетной и не должна отображаться в разделе ответов авторитетного ответа. Потенциально его можно использовать в качестве связующих данных, которые отображаются в дополнительном разделе направления, но это все.

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

7

Запись A сопоставляет имя с IP-адресом. например

двоичный.example.com. В А 192.168.1.42
 

указывает, что binary.example.com. разрешается в 192.168.1.42

NS-запись сопоставляет имя с другим сервером имен, то есть другим DNS-сервером, который обслуживает этот домен. то есть «Я понятия не имею об IP-адресе этого имени, но если вы спросите этот сервер имен, он может знать»

двоичный.example.com. В NS otherbox.example.com
otherbox.example.com. В А 192.168.1.2
 

Если вы спросите DNS-сервер, который имеет 2 указанные выше записи для binary.example.com. (или www.binary.example.com. или foo.bar.binary.example.com). он скажет вам, что вам нужно будет попросить 192.168.1.2 перевести эти имена (ну, или DNS-сервер может сделать это за вас, или он может кэшировать разрешенные имена и вернуть их вам.)

3

Важно иметь записи NS и A в зоне, если вам нужно делегировать подзону другому DNS-серверу.

у нас есть dns сервер ns1.bar.com авторитетный для зоны bar.com. И нам нужно делегировать foo.bar.com ns1.foo.bar.com. Итак, нам нужно создать зону foo.bar.com и поместить туда следующие записи:

 foo.bar.com. В НС ns1.foo.bar.com.
ns1.foo.bar.com. В А 10.10.10.10
 

Если у нас не будет A записи делегирования не будет работать. Такие пары записей называются связующими записями.

Склеивание записей — это единственный способ для системы DNS найти точный IP-адрес авторитетного DNS-сервера для некорневой зоны. Если вы проверите любой домен на наличие записи NS, используя dig , или посмотрите дамп трафика с помощью wireshark, вы увидите, что в ответе есть «дополнительный» раздел.

 ;; РАЗДЕЛ ОТВЕТОВ:
foo.bar.com. 10800 В NS ns1.foo.bar.com.
;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ:
ns1.foo.bar.com. 7972 В А 10.10.10.10
 

при выполнении рекурсивного запроса, например. www.foo.bar.com ваш DNS-клиент запросит полномочный DNS для зоны foo.bar. com и получит ответ ns1.foo.bar.com.

Для дальнейшего прохождения необходимо отправить запрос на ns1.foo.bar.com, который обслуживается… ns1.foo.bar.com. Чтобы разорвать цикл, делегирующий DNS-сервер должен добавить этот дополнительный раздел с записью A.

Сервер ns1.foo.bar.com должен иметь такие же записи в своей зоне, чтобы он мог быть авторитетным для зоны foo.bar.com.

2

Записи NS указывают серверы, предоставляющие услуги DNS для этого доменного имени.

Записи A указывают имена хостов (например, www, ftp, mail) на один или несколько IP-адресов.

Записи NS существуют ИСКЛЮЧИТЕЛЬНО с целью определения, КАКИЕ СЕРВЕРЫ ИМЕН несут ответственность за конкретный домен.

Существует запись A для «АДРЕСА» конкретной машины или службы.

Примеры для вас:

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

NS1.CP.COM NS2.CP.COM

Также внутри вашей панели DNS у вас будет домен, которым вы владеете (например, -mikesfunhouse.com), на котором вам нужны некоторые услуги, например веб-сайт.

Итак, что вам нужно сделать, так это иметь первичную запись A, указывающую «mikesfunhouse.com» на «76.19.87.956» (очевидно, поддельный IP-адрес).

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

Короче говоря, вы используете записи A для преобразования пространства имен в IP-адрес.

Запись сервера имен сообщает Интернету, какой DNS-сервер содержит записи A, поэтому поиск записи A для поддомена выполняется примерно следующим образом:

Поиск серверов имен для домена -> Запросить сервер имен для записи A поддомена.

2

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Обязательно, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie

Какова роль записей NS на вершине домена DNS?

Идентификация подчиненного

Записи NS уровня Apex используются главным сервером для идентификации подчиненных. Когда данные об авторитетном сервере имен изменяются, он сообщает об этом через DNS NOTIFY сообщений (RFC 1996) всем одноранговым узлам в этом списке. Эти серверы, в свою очередь, перезвонят с запросом записи SOA (которая содержит серийный номер) и примут решение о том, следует ли извлечь более новую копию этой зоны.

• Можно отправлять эти сообщения на серверы, не указанные в разделе NS , но для этого требуются директивы конфигурации для конкретного сервера (например, директива ISC BIND также-уведомить ). Записи апекса NS содержат базовый список серверов, о которых следует уведомлять в конфигурации по умолчанию.
• Стоит отметить, что вторичные серверы также будут отправлять сообщения NOTIFY друг другу на основе этих записей NS , что обычно приводит к зарегистрированным отказам. Это можно отключить, указав серверам отправлять уведомления только для зон, для которых они являются главными (BIND: notify master; ), или полностью пропускать уведомления на основе NS в пользу уведомлений, явно определенных в конфигурации. (BIND: явное уведомление; )

Авторитетное определение

Вопрос выше содержал ошибку:

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

К такому выводу легко прийти, но он не точен. Записи NS и данные связующих записей (например, определенные в вашей учетной записи регистратора) не являются авторитетными. Само собой разумеется, что их нельзя считать «более авторитетными», чем данные, находящиеся на серверах, которым делегируются полномочия. Это подчеркивается тем, что у рефералов нет aa (Авторитетный ответ) флаг установлен.

Для иллюстрации:

 $ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 14021
;; флаги: qr; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИЗАЦИЯ: 2, ДОПОЛНИТЕЛЬНО: 5
;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
;; РАЗДЕЛ ВОПРОСОВ:
;example.com. В NS
;; ОТДЕЛ ПОЛНОМОЧИЙ:
пример.com. 172800 В NS a.iana-servers.net.
пример.com. 172800 В NS b.iana-servers.net.
;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ:
a.iana-servers.net. 172800 В А 199.43.135.53
a.iana-servers.net. 172800 В АААА 2001:500:8f::53
b.iana-servers.net. 172800 В А 199.43.133.53
b.iana-servers.net. 172800 В АААА 2001:500:8d::53
 

Обратите внимание на отсутствие aa во флагах ответа выше. Само обращение не является авторитетным. С другой стороны, данные на сервере, на которые ссылаются , являются авторитетными.

 $ dig @a. iana-servers.net +norecurse +nocmd example.com. NS
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 2349;; флаги: qr aa; ЗАПРОС: 1, ОТВЕТ: 2, АВТОРИЗАЦИЯ: 0, ДОПОЛНИТЕЛЬНО: 1
;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
;; РАЗДЕЛ ВОПРОСОВ:
;example.com. В NS
;; РАЗДЕЛ ОТВЕТОВ:
пример.com. 86400 В NS a.iana-servers.net.
пример.com. 86400 В NS b.iana-servers.net.
 

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

• Краткий ответ: «непоследовательное поведение».
• Длинный ответ заключается в том, что серверы имен изначально будут заглушать все ссылки (и склеивать) в пустой кэш, но эти записи NS , A и AAAA могут в конечном итоге быть заменены при их обновлении. Обновление происходит по мере истечения срока жизни этих временных записей или когда кто-то явным образом запрашивает ответ для этих записей.
• A и AAAA записи для данных вне зоны (т. е. серверы имен com , определяющие клей для данных вне зоны com , например example.net ) определенно будут обновлены, как это хорошо понятая концепция, согласно которой сервер имен не должен считаться авторитетным источником такой информации. (RFC 2181)
• Когда значения записей NS различаются между родительской и дочерней сторонами ссылки (например, серверы имен, введенные в панель управления регистратором, отличаются от NS , которые находятся на тех же серверах), поведение будет непоследовательным, вплоть до дочерних NS записей включительно, которые будут полностью игнорироваться. Это связано с тем, что поведение недостаточно четко определено стандартами, а реализация различается в разных реализациях рекурсивного сервера. Другими словами, согласованное поведение в Интернете можно ожидать только в том случае, если определения серверов имен для домена согласованы между родительской и дочерней сторонами ссылки 9.0032 .

Суть в том, что рекурсивные DNS-серверы в Интернете будут возвращаться между пунктами назначения, если записи, определенные на родительской стороне ссылки, не согласуются с официальными версиями этих записей. Первоначально данные, представленные в направлении, будут предпочтительными, но только для замены авторитетными определениями. Поскольку кэши в Интернете постоянно перестраиваются с нуля, Интернет не может установить единую версию реальности с такой конфигурацией. Если авторитетные записи делают что-то незаконное в соответствии со стандартами, например, указывая NS записывает псевдонимы, определенные CNAME , это становится еще более трудным для устранения неполадок; домен будет чередоваться между рабочим и неработающим для программного обеспечения, которое отклоняет нарушение. (т. е. ISC BIND / named)

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

 5.4.1. Данные рейтинга
 При рассмотрении вопроса о том, принять ли RRSet в ответ или сохранить
 RRSet уже в своем кеше, вместо этого сервер должен учитывать
 относительная вероятность достоверности различных данных. Ан
 авторитетный ответ из ответа должен заменить кэшированные данные, которые были
 была получена из дополнительной информации в более раннем ответе.
 Однако дополнительная информация из ответа будет проигнорирована, если
 cache содержит данные из авторитетного ответа или файла зоны.
 Точность имеющихся данных исходит из их источника.
 Надежность определяется в порядке от большего к меньшему:
 + Данные из файла первичной зоны, кроме данных клея,
 + Данные из зоны передачи, кроме клея,
 + Официальные данные, включенные в раздел ответов
 авторитетный ответ.
No related posts.