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

16.03.1970 alexxlab

Содержание

Вопросы и ответы по Amazon Route 53 – Amazon Web Services

Вопрос. Что такое обработка отказа сервиса DNS?

Переброс сервиса DNS включает в себя два этапа: проверка работоспособности и собственно переброс. Проверка работоспособности представляет собой автоматический запрос, отправляемый приложению через Интернет для проверки его доступности и работоспособности. Можно настроить аналогичные способы проверок работоспособности для типичных запросов пользователей, таких как запрос веб-страницы с некоторого адреса URL. При использовании переброса сервиса DNS сервис Route 53 возвращает ответы только для тех ресурсов, которые работоспособны и доступны. Благодаря этому ваши конечные пользователи будут перенаправлены с отказавших или неработоспособных компонентов вашего приложения.

Вопрос. Как начать использовать функцию обработки отказа сервиса DNS?

Подробные инструкции по началу работы вы найдете в руководстве разработчика Amazon Route 53.

Настроить функцию переброса сервиса DNS можно также из консоли управления Route 53.

Вопрос. Поддерживается ли при обработке отказа переключение сервиса DNS на балансировщики нагрузки сервиса Elastic Load Balancing (ELB)?

Да, вы можете настроить переброс сервиса DNS на балансировщики нагрузки ELB. Для переброса сервиса DNS на адрес балансировщика ELB нужно создать запись псевдонима, указывающую на балансировщик нагрузки ELB, и для параметра Evaluate Target Health задать значение true. Route 53 автоматически выполняет проверку работоспособности ваших балансировщиков ELB, и вам не требуется делать этого самостоятельно. Вам также не требуется связывать ресурсную запись балансировщика ELB с самостоятельно созданной проверкой работоспособности. Сервис Route 53 автоматически свяжет эту запись с проверками работоспособности, создаваемыми от вашего имени. Проверка работоспособности ELB также определяет работоспособность серверных инстансов, на которых работают данные балансировщики ELB. Подробные сведения об использовании функции переброса сервиса DNS с конечными точками ELB см. в Руководстве разработчика по Amazon Route 53.

Вопрос. Можно ли настроить резервный сайт, который будет использоваться только в случае неработоспособности основного?

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

Вопрос. Для каких типов записей DNS можно выполнять проверку работоспособности Route 53?

Проверить можно любой тип записи, поддерживаемый сервисом Route 53, кроме записей SOA и NS.

Вопрос. Можно ли выполнить проверку работоспособности URL сервера, если его IP-адрес неизвестен?

Да. Можно настроить переброс сервиса DNS для балансировщиков Elastic Load Balancers и корзин Amazon S3 с помощью Консоли Amazon Route 53. При этом необязательно создавать собственную проверку работоспособности. Для таких типов конечных точек сервис Route 53 автоматически создает и управляет проверками работоспособности вместо пользователя. Они используются, когда пользователь создает запись псевдонима, указывающую на ELB или корзину Amazon S3, и включает в этой записи параметр Evaluate Target Health.

При создании проверки работоспособности для любых других конечных точек можно указать либо имя DNS точки (например, www.example.com), либо IP-адрес.

Вопрос. Один из моих URL-адресов находится за пределами AWS. если он расположен не на платформе AWS?

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

Вопрос. Если в ситуации переброса имеется несколько работоспособных конечных точек, будет ли сервис Route 53 учитывать уровень нагрузки на них во время принятия решения о том, куда направить трафик с неработоспособной конечной точки?

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

Вопрос. Сколько последовательных проверок работоспособности URL сервера должны закончиться неудачей, чтобы он считался неработоспособным?

По умолчанию предел составляет три проверки работоспособности. Если конечная точка не пройдет три проверки подряд, сервис Route 53 посчитает ее неработоспособной. Однако сервис Route 53 продолжит выполнять проверки работоспособности и направлять трафик к этой конечной точке, когда она пройдет три проверки работоспособности подряд. Предел можно устанавливать в диапазоне 1–10 проверок. Дополнительную информацию см. в Руководстве разработчика по Amazon Route 53.

Вопрос. Каким образом будет выполнен обратный переброс сервиса DNS после возобновления работоспособного состояния конечной точки?

Если отказавшая конечная точка пройдет заданное количество последовательных проверок работоспособности, указываемое при создании проверки (по умолчанию – три проверки подряд), сервис Route 53 автоматически восстановит записи DNS. Трафик будет снова направляться к этой конечной точке без необходимости вмешательства пользователя.

Вопрос. С какой периодичностью выполняется проверка работоспособности?

По умолчанию проверки работоспособности выполняются каждые 30 секунд. Можно выбрать более короткий промежуток в 10 секунд.

При выборе более короткого промежутка сервис Route 53 сможет быстрее определить отказ конечной точки, в результате чего переброс сервиса DNS и перенаправление трафика произойдут быстрее.

Частые проверки работоспособности приводят к увеличению запросов к конечной точке в три раза, что следует учитывать, если конечная точка имеет ограниченные ресурсы для обработки сетевого трафика. См. страницу цен сервиса Route 53 для получения сведений о ценах на использование частых проверок работоспособности и других дополнительных функций. Дополнительную информацию см. в Руководстве разработчика по Amazon Route 53.

Вопрос. Какую нагрузку на конечную точку (например, на веб-сервер) создает процедура проверки работоспособности?

Каждая проверка работоспособности выполняется из нескольких местоположений по всему миру. Количество и набор местоположений настраивается, вы можете изменять количество местоположений, из которых проводится каждая из проверок работоспособности, с помощью консоли Amazon Route 53 или API. Каждое местоположение проверяет URL сервера независимо от других через заданный пользователем интервал (по умолчанию – 30 секунд, альтернативный ускоренный вариант – 10 секунд). Учитывая текущее стандартное количество местоположений, выполняющих проверку работоспособности, URL сервера будет получать запрос каждые 2–3 секунды при стандартном интервале проверок и один или несколько запросов в секунду при более частом интервале проверок.

Вопрос. Проверки работоспособности Route 53 следуют после выполнения переадресации HTTP?

Нет. Проверки работоспособности сервиса Route 53 рассматривают коды HTTP 3xx как успешный результат, поэтому они не переходят по перенаправлениям. Это может приводить к неожиданным результатам для проверок на совпадение строк. Проверка работоспособности выполняет поиск указанной строки в теле перенаправления. Поскольку проверка работоспособности не выполняет переход, она не отправляет запрос в указанное в перенаправлении местоположение и не получает от него ответ. Для проверок на совпадение строк рекомендуется не настраивать проверку работоспособности на местоположение, которое возвращает перенаправление HTTP.

Вопрос. Какова последовательность событий при выполнении переброса?

При неуспешной проверке работоспособности и перебросе сервиса произойдут следующие события:

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

Сервис Route 53 отключает записи ресурсов в отказавшей конечной точке и больше не обслуживает их. Это и есть этап переброса, в результате которого трафик начнет перенаправляться в работоспособную конечную точку или несколько точек.

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

Промежуток времени, в течение которого преобразователь адресов DNS сохраняет в кэше ответ, определяется значением, которое называют временем жизни. Этот параметр определяется для каждой записи. При использовании переброса сервиса DNS рекомендуется устанавливать параметр TTL в значение не более 60 секунд, чтобы минимизировать время, необходимое для остановки направления трафика в отказавшую конечную точку. При настройке переброса сервиса DNS для конечных точек ELB и Amazon S3 следует использовать записи псевдонимов с фиксированным значением TTL 60 секунд. Для этих типов конечных точек нет необходимости настраивать значения TTL, чтобы можно было использовать переброс сервиса DNS.

Вопрос. Что произойдет, если все конечные точки окажутся неработоспособными?

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

Вопрос. Можно ли использовать функцию переброса сервиса DNS, не применяя маршрутизацию на основе задержки (LBR)?

Да. Можно настроить переброс сервиса DNS без применения LBR. В частности, можно использовать переброс сервиса DNS для настройки простых сценариев переброса, в которых сервис Route 53 контролирует основной веб-сайт и переключается на резервный, когда основной станет недоступным.

Вопрос. Можно ли настроить выполнение проверки работоспособности сайта, доступ к которому осуществляется только по HTTPS?

Да. Сервис Route 53 поддерживает проверки работоспособности по протоколам HTTPS, HTTP и TCP.

Вопрос. Выполняется ли при проверке работоспособности URL сервера с доступом по HTTPS проверка сертификата SSL?

Нет. Проверки работоспособности по протоколу HTTPS проверяют, можно ли подключиться к конечной точке по протоколу SSL и возвращает ли она действительный код ответа HTTP. Но такие проверки не проверяют SSL-сертификат, возвращаемый конечной точкой.

Вопрос. Поддерживается ли при проверке работоспособности конечной точки с доступом по HTTPS индикация имени сервера (SNI)?

Да, при проверке работоспособности по протоколу HTTPS поддерживается индикация имени сервера (SNI).

Вопрос. Как с помощью проверок работоспособности убедиться, что веб-сервер возвращает корректный контент?

Проверки работоспособности сервиса Route 53 можно использовать для проверки наличия требуемой строки в ответе сервера, выбрав опцию Enable String Matching. Такой вариант можно применять для проверки, содержит ли передаваемый сервером HTML-контент ожидаемую строку. Также можно создать отдельную страницу состояния и проверять состояние сервера с точки зрения внутренних процессов и операций. Дополнительную информацию см. в Руководстве разработчика по Amazon Route 53.

Вопрос. Как просмотреть состояние созданной проверки работоспособности?

Текущее состояние проверки работоспособности, а также причину, по которой она не была пройдена, можно посмотреть в консоли Amazon Route 53 или с помощью API сервиса Route 53.

Кроме того, все результаты проверки работоспособности публикуются в виде метрик Amazon CloudWatch. Они содержат работоспособность конечной точки, а также задержку ее ответа. Текущее и предыдущие состояния проверки работоспособности можно найти на графике метрики Amazon CloudWatch, расположенном во вкладке проверок работоспособности консоли Amazon Route 53. Для метрики можно также создать предупреждения Amazon CloudWatch, чтобы сервис отправлял оповещения при изменении состояния проверки работоспособности.

Метрики Amazon CloudWatch для всех проверок работоспособности Amazon Route 53 также доступны в консоли Amazon CloudWatch. Каждая метрика Amazon CloudWatch включает параметр Health Check ID (например, 01beb6a3-e1c2-4a2b-a0b7-7031e9060a6a), который используется для определения, какую проверку отслеживает метрика.

Вопрос. Как можно измерить производительность URL сервера в приложении с помощью Amazon Route 53?

Проверка работоспособности Amazon Route 53 включает дополнительную функцию измерения задержки, которая возвращает данные о времени, в течение которого конечная точка отвечает на запрос. При включении функции измерения задержки проверка работоспособности Amazon Route 53 создаст дополнительные метрики Amazon CloudWatch, отображающие время, которое потребовалось средствам проверки работоспособности Amazon Route 53, чтобы установить соединение и начать передачу данных. Amazon Route 53 возвращает отдельный набор метрик задержки для всех регионов AWS, в которых выполняется проверка работоспособности Amazon Route 53.

Вопрос. Каким образом можно получать оповещения о том, что проверки работоспособности некоторой конечной точки заканчиваются неудачей?

Каждая проверка работоспособности сервиса Route 53 выводит результаты в метрике CloudWatch. Можно настроить широкий диапазон оповещений и автоматических действий CloudWatch, срабатывающих, когда значение проверки работоспособности выходит за указанный предел. Сначала в консоли Route 53 или CloudWatch настройте предупреждение CloudWatch для метрики проверки работоспособности. Затем добавьте действие оповещения и укажите электронный адрес или тему SNS, на которые следует отправить оповещение. Полную информацию см. в Руководстве разработчика по Amazon Route 53.

Вопрос. Я создал(а) предупреждение для проверок работоспособности, но требуется повторно отправить письмо подтверждения для связанной с ним темы SNS. Как это сделать?

Письмо с подтверждением можно повторно отправить из консоли SNS. Чтобы найти название темы SNS, связанной с конкретным предупреждением, щелкните название предупреждения в консоли Route 53 и посмотрите в поле «Send notification to» (Отправить уведомление для).

В консоли SNS разверните список тем и выберите тему для предупреждения. Откройте поле Create Subscription, выберите протокол электронной почты и введите требуемый электронный адрес. Нажатие на кнопку «Subscribe» приведет к повторной отправке письма с подтверждением.

Вопрос. Я применяю обработку отказа сервиса DNS с переключением на балансировщики нагрузки сервиса Elastic Load Balancing (ELB). Как просмотреть их состояние?

Для настройки переброса сервиса DNS с конечными точками ELB рекомендуется использовать записи псевдонимов с опцией Evaluate Target Health. При использовании этой опции не нужно создавать собственные проверки работоспособности для конечных точек ELB, поэтому сервис Route 53 не создает для них отдельные метрики CloudWatch.

Эти метрики работоспособности балансировщика нагрузки можно получить двумя способами. Во-первых, сервис Elastic Load Balancing создает метрики, указывающие работоспособность балансировщика нагрузки и связанных с ним работоспособных инстансов. Подробную информацию о настройке метрик CloudWatch для балансировщиков ELB см. в Руководстве разработчика по ELB. Во-вторых, можно создать собственную проверку работоспособности для параметра CNAME, предоставляемого балансировщиком ELB, например elb-example-123456678.us-west-2.elb.amazonaws.com. Эту проверку нельзя будет использовать для переброса сервиса DNS (потому что опция Evaluate Target Health уже предоставляет переброс сервиса DNS), но вы сможете просмотреть метрики CloudWatch для данной проверки и создать предупреждения для оповещения о непройденной проверке.

Полную информацию об использовании переброса сервиса DNS с конечными точками ELB см. в Руководстве разработчика по Amazon Route 53.

Вопрос. Для записей псевдонимов, указывающих на корзины веб-сайта Amazon S3: какие параметры проходят проверку работоспособности, если задать значение true для опции Evaluate Target Health?

Amazon Route 53 выполняет проверку работоспособности сервиса Amazon S3 во всех регионах AWS. При включении функции Evaluate Target Health для псевдонима, указывающего на корзину веб-сайта Amazon S3, Amazon Route 53 проверит состояние сервиса Amazon S3 в регионе AWS, в котором расположена эта корзина. Amazon Route 53 не проверяет существование соответствующей корзины и наличие действительного содержимого веб-сайта; Amazon Route 53 способен выполнить только аварийный переброс в другое местоположение, если сервис Amazon S3 будет недоступен в регионе AWS, в котором расположена эта корзина.

Вопрос. Какова стоимость использования метрик CloudWatch при выполнении проверок работоспособности в Route 53?

Метрики CloudWatch для проверок работоспособности Route 53 бесплатны.

Вопрос. Можно ли настраивать переброс сервиса DNS на основе внутренних метрик работоспособности, таких как нагрузка на ЦПУ, состояние сети или памяти?

Да. Проверки работоспособности сервисом Amazon Route 53 на основе метрик позволяют выполнять переброс сервиса DNS на основе любой метрики, доступной в рамках Amazon CloudWatch, включая предоставляемые AWS метрики и пользовательские метрики ваших приложений. Если в Amazon Route 53 создана проверка работоспособности на основе метрик, такая проверка возвращает результат «состояние неработоспособности» всякий раз, когда связанная с проверкой метрика Amazon CloudWatch переходит в состояние предупреждения.

Проверки работоспособности на основе метрик удобно применять для переброса сервиса DNS для URL серверов, которые нельзя проверить стандартной проверкой работоспособности сервиса Amazon Route 53, таких как инстансы внутри виртуального частного облака (VPC), имеющего только частные IP-адреса Используя функцию Amazon Route 53 расчетной проверки работоспособности можно также осуществить более сложные сценарии обработки отказов, сочетая результаты проверок работоспособности на основе метрик с результатами стандартных проверок работоспособности сервисом Amazon Route 53, которые делают запросы в отношении URL сервера от сети средств проверки работоспособности по всему миру. Например, вы можете создать конфигурацию проверки работоспособности, при которой URL сервера будет признан неработоспособным в случае, если недоступна его публичная веб-страница либо его неработоспособность показывают такие внутренние метрики, как загрузка ЦПУ, объем сетевого входящего/исходящего трафика или количество дисковых операций чтения и записи.

Вопрос. Мой веб-сервер получает от сервиса Route 53 запросы проверки работоспособности, которых я не создавал(а). Как прекратить подобные запросы?

Бывает, что клиенты сервиса Amazon Route 53 создают запросы проверки работоспособности с указанием IP-адреса или домена, которые им не принадлежат. Если ваш веб-сервер получает нежелательные запросы HTTP(s), которые исходят от сервиса Amazon Route 53 и связаны с проверкой работоспособности, просим сообщить об этой нежелательной проверке, заполнив форму, и мы свяжемся с нашим клиентом для решения данной проблемы.

Вопрос. Если указать доменное имя в качестве целевого для проверки работоспособности, по какому протоколу Amazon Route 53 будет выполнять проверку, IPv4 или IPv6?

Если указать имя домена в качестве URL сервера для проверки работоспособности сервисом Amazon Route 53, Amazon Route 53 найдет адрес IPv4 этого доменного имени и подключится к URL сервера по протоколу IPv4. Amazon Route 53 не будет пытаться найти адрес IPv6 для URL серверов, определенных именем домена. Если нужно выполнить проверку работоспособности по протоколу IPv6, а не IPv4, следует в качестве типа адреса/URL сервера вместо «domain name» выбрать «IP address» и ввести в поле «IP address» значение адреса IPv6.

Вопрос. Где можно узнать диапазоны адресов IPv6 для серверов DNS и средств проверки работоспособности Amazon Route 53?

AWS в настоящее время публикует свои диапазоны IP-адресов в формате JSON. Чтобы узнать текущие диапазоны, загрузите файл .json по следующей ссылке. Если доступ к этому файлу осуществляется программно, примите меры к тому, чтобы приложение загружало файл только после успешной проверки сертификата TLS, возвращаемого сервером AWS.

Загрузить: ip-ranges.json

Чтобы определить диапазоны IP-адресов серверов Route 53, ищите в поле «service» следующие значения.

Серверы DNS сервиса Route 53: искать «ROUTE53»

Средства проверки работоспособности сервиса Route 53: искать «ROUTE53_HEALTHCHECKS»

Дополнительную информацию см. в разделе Диапазоны IP-адресов AWS в общих справочных материалах по Amazon Web Services.

Имейте в виду, что диапазоны адресов IPv6 на настоящий момент могут отсутствовать в этом файле. Для справки: диапазоны адресов IPv6 для средств проверки работоспособности сервиса Amazon Route 53 перечислены ниже.

2600:1f1c:7ff:f800::/53
2a05:d018:fff:f800::/53
2600:1f1e:7ff:f800::/53
2600:1f1c:fff:f800::/53
2600:1f18:3fff:f800::/53
2600:1f14:7ff:f800::/53
2600:1f14:fff:f800::/53
2406:da14:7ff:f800::/53
2406:da14:fff:f800::/53
2406:da18:7ff:f800::/53
2406:da1c:7ff:f800::/53
2406:da1c:fff:f800::/53
2406:da18:fff:f800::/53
2600:1f18:7fff:f800::/53
2a05:d018:7ff:f800::/53
2600:1f1e:fff:f800::/53
2620:107:300f::36b7:ff80/122
2a01:578:3::36e4:1000/122
2804:800:ff00::36e8:2840/122
2620:107:300f::36f1:2040/122
2406:da00:ff00::36f3:1fc0/122
2620:108:700f::36f4:34c0/122
2620:108:700f::36f5:a800/122
2400:6700:ff00::36f8:dc00/122
2400:6700:ff00::36fa:fdc0/122
2400:6500:ff00::36fb:1f80/122
2403:b300:ff00::36fc:4f80/122
2403:b300:ff00::36fc:fec0/122
2400:6500:ff00::36ff:fec0/122
2406:da00:ff00::6b17:ff00/122
2a01:578:3::b022:9fc0/122
2804:800:ff00::b147:cf80/122

Руководство по размещению домена и дочернего домена в Azure DNS

04/19/2021
Чтение занимает 4 мин

В этой статье

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

Предположим, вы приобретаете домен contoso.net у регистратора доменных имен, после чего создаете зону с именем contoso.net в Azure DNS. Регистратор предоставляет вам как владельцу домена возможность настройки записей сервера имен (NS) для домена. Регистратор будет хранить эти записи сервера имен в родительской зоне .NET. Пользователи Интернета по всему миру будут направляться в ваш домен в зоне Azure DNS при попытке разрешить записи DNS в contoso.net.

В этом руководстве описано следующее:

создание зоны DNS;
получение списка серверов имен;
делегирование домена;
проверка работы делегирования имен.

Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.

Предварительные требования

У вас должно быть доступное доменное имя, которое можно будет разместить в Azure DNS и использовать для тестирования. У вас должен быть полный контроль над этим доменом, включая возможность определять записи сервера имен (NS) для домена.

В контексте данного примера мы будем ссылаться на родительский домен на contoso.net.

Создание зоны DNS

Перейдите на портал Azure, чтобы создать зону DNS. Найдите в поиске и выберите зоны DNS.
Выберите Создание зоны DNS.

На странице Создать зону DNS введите следующие значения, после чего выберите Создать. Например, contoso.net.

Параметр	Значение	Сведения
Группа ресурсов	ContosoRG	Создайте группу ресурсов. Имя группы ресурсов должно быть уникальным в пределах выбранной подписки. Расположение группы ресурсов никак не влияет на зону DNS. Расположение зоны DNS всегда является глобальным и не отображается.
Zone child (Дочерний элемент зоны)	Не устанавливайте флажок.	Не устанавливайте этот флажок, так как эта зона не является дочерней.
имя;	`contoso.net`	Поле для имени родительской зоны.
Расположение	Восточная часть США	Значение в этом поле зависит от расположения, выбранного при создании группы ресурсов.

Получение серверов имен

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

Создав зону DNS, на портале Azure на панели Избранное выберите Все ресурсы. На странице Все ресурсы выберите зону DNS. Если выбранная подписка имеет несколько ресурсов, введите доменное имя в поле Фильтровать по имени для получения доступа к шлюзу приложений.
Получите серверы имен на странице «Зона DNS». В данном примере зоне contoso.net были назначены серверы имен ns1-01.azure-dns.com, ns2-01.azure-dns.net, *ns3-01.azure-dns.org и ns4-01.azure-dns.info:

Служба Azure DNS автоматически создает в зоне заслуживающие доверия записи NS для назначенных серверов имен.

Делегирование домена

После того, как зона DNS будет создана и у вас появятся серверы имен, вам необходимо обновить родительский домен, добавив в него серверы имен Azure DNS. У каждого регистратора есть собственные средства управления DNS для изменения записей серверов имен домена.

На странице управления DNS регистратора замените записи NS на серверы имен Azure DNS.
При делегировании домена в Azure DNS вам необходимо использовать серверы имен, предоставленные службой Azure DNS. Используйте все четыре сервера имен, независимо от имени домена. Для делегирования домена не требуется, чтобы в сервере имен и вашем домене содержался один и тот же домен верхнего уровня.

Примечание

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

Делегирование с использованием серверов имен в собственной зоне (также известны как серверы личных имен) в настоящее время не поддерживается в Azure DNS.

Проверка делегирования

По завершении делегирования можно проверить, работает ли разрешение имен. Это можно сделать с помощью такого средства, как nslookup, запросив запись SOA (начальная запись зоны) для зоны. Запись SOA автоматически создается при создании зоны. Возможно, вам придется подождать не менее 10 минут после завершения делегирования, прежде чем вы сможете успешно убедиться, что процедура работает. Для изменений в системе DNS может потребоваться некоторое время.

Нет необходимости указывать серверы имен Azure DNS. Если делегирование настроено правильно, в ходе обычного процесса разрешения DNS серверы имен находятся автоматически.

В командной строке введите команду nslookup, аналогичную следующему примеру:
```
nslookup -type=SOA contoso.net
```

Убедитесь, что ваш ответ будет выглядеть аналогично приведенным ниже выходным данным nslookup:

Server: ns1-04.azure-dns.com
Address: 208.76.47.4

contoso.net
primary name server = ns1-04.azure-dns.com
responsible mail addr = msnhst.microsoft.com
serial = 1
refresh = 900 (15 mins)
retry = 300 (5 mins)
expire = 604800 (7 days)
default TTL = 300 (5 mins)

Очистка ресурсов

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

Выберите группу ресурсов contosoRG и щелкните Удалить группу ресурсов.

Дальнейшие действия

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

Изменение именных имен для Microsoft 365 с любым регистратором домена — Microsoft 365 admin

13.07.2021
Чтение занимает 6 мин

В этой статье

Если вы не нашли то, что вы ищете, см. раздел Вопросы и ответы по доменам.Check the Domains FAQ if you don’t find what you’re looking for.

Следуйте этим инструкциям, чтобы добавить и настроить домен в Microsoft 365, чтобы ваши службы, такие как электронная почта и Teams, использовали собственное доменное имя.Follow these instructions to add and set up your domain in Microsoft 365 so your services like email and Teams will use your own domain name. Для этого необходимо проверить домен, а затем изменить имена домена на Microsoft 365, чтобы можно было настроить правильные записи DNS.To do this, you’ll verify your domain, and then change your domain’s nameservers to Microsoft 365 so the correct DNS records can be set up for you. Выполните следующие действия, если в следующих утверждениях описана ваша ситуация:Follow these steps if the following statements describe your situation:

Добавьте запись TXT или MX для проверкиAdd a TXT or MX record for verification

Примечание

Нужно создать только одну из этих записей. TXT является предпочтительным типом, но некоторые поставщики услуг размещения DNS не поддерживают его. В таком случае можно создать MX-запись.You will create only one or the other of these records. TXT is the preferred record type, but some DNS hosting providers don’t support it, in which case you can create an MX record instead.

Прежде чем вы сможете использовать свой домен в Microsoft 365, мы должны убедиться в том, что вы являетесь его владельцем. Если вы войдете в свою учетную запись на сайте регистратора доменных имен и создадите запись DNS, это послужит для Microsoft 365 подтверждением того, что вы владеете доменом.Before you use your domain with Microsoft 365, we have to make sure that you own it. Your ability to log in to your account at your domain registrar and create the DNS record proves to Microsoft 365 that you own the domain.

Примечание

Эта запись используется исключительно для проверки принадлежности домена. При желании вы сможете удалить ее позже.This record is used only to verify that you own your domain; it doesn’t affect anything else. You can delete it later, if you like.

Найдите область на веб-сайте поставщика хостинга DNS, в которой можно создать новую записьFind the area on your DNS hosting provider’s website where you can create a new record

Войдите на сайт поставщика услуг размещения DNS.Sign in to your DNS hosting provider’s website.
Выберите свой домен.Choose your domain.
Найдите страницу, на которой можно редактировать DNS-записи для домена.Find the page where you can edit DNS records for your domain.

Создание записиCreate the record

При создании записи TXT или MX следуйте соответствующим инструкциям.Depending on whether you are creating a TXT record or an MX record, do one of the following:

Для создания TXT-записи используйте следующие значения:If you create a TXT record, use these values:

Тип записиRecord type	Псевдоним или имя хозяинаAlias or host name	ЗначениеValue	TTLTTL
TXTTXT	Выполните одно из следующих действий: Введите @, оставьте поле пустым или укажите имя своего домена.Do one of the following: Type @ or leave the field empty or type your domain name. Примечание. Различные DNS-хосты имеют различные требования к этому полю.Note: Different DNS hosts have different requirements for this field.	MS=ms XXXXXXXXMS=ms XXXXXXXX Примечание. Это пример.Note: This is an example. Используйте здесь собственное значение Назначение или адрес «указывает на» из таблицы в Microsoft 365.Use your specific Destination or Points to Address value here, from the table in Microsoft 365. Как его найти?How do I find this?	Задайте для этого значения 1 hour (1 час) или эквивалент в минутах ( 60 ), секундах ( 3600 ) и т. д.Set this value to 1 hour or to the equivalent in minutes ( 60 ), seconds ( 3600 ), etc.

Для создания MX-записи используйте следующие значения:If you create an MX record, use these values:

Тип записиRecord type	Псевдоним или имя хозяинаAlias or host name	ЗначениеValue	Priority (Приоритет)Priority	TTL (Срок жизни)TTL
MXMX	Введите знак @ или имя своего домена.Type either @ or your domain name.	ПРИМЕЧАНИЕ MS=ms XXXXXXXXXX: Вот пример.MS=ms XXXXXXXX Note: This is an example. Используйте здесь собственное значение Назначение или адрес «указывает на» из таблицы в Microsoft 365.Use your specific Destination or Points to Address value here, from the table in Microsoft 365. Как его найти?How do I find this?	В поле Priority (Приоритет) используйте более низкое значение приоритета, чем указанное для других записей MX, во избежание конфликтов с записью MX, используемой для потока обработки почты.For Priority, to avoid conflicts with the MX record used for mail flow, use a lower priority than the priority for any existing MX records. Дополнительные сведения о приоритете см. в статье Что такое приоритет записей MX?.For more information about priority, see What is MX priority?	Задайте для этого значения 1 hour (1 час) или эквивалент в минутах ( 60 ), секундах ( 3600 ) и т. д.Set this value to 1 hour or to the equivalent in minutes ( 60 ), seconds ( 3600 ), etc.

Сохранение записиSave the record

Теперь, когда запись добавлена на сайте регистратора доменных имен, вернитесь в Microsoft 365 и подайте запрос на ее поиск.Now that you’ve added the record at your domain registrar’s site, you’ll go back to Microsoft 365 and request Microsoft 365 to look for the record.

Если Microsoft 365 обнаружит правильную запись TXT, это значит, что домен проверен.When Microsoft 365 finds the correct TXT record, your domain is verified.

В Центре администрирования перейдите на страницу Settings (Параметры) > Domains (Домены).In the admin center, go to the Settings > Domains page.
На странице Domains (Домены) выберите домен, который нужно проверить.On the Domains page, select the domain that you are verifying.
На странице Setup (Настройка) выберите Start setup (Начать настройку).On the Setup page, select Start setup.
На странице Проверка домена выберите Проверить.On the Verify domain page, select Verify.

Примечание

Обычно на вступление изменений DNS в силу требуется около 15 минут. Однако иногда распространение внесенного изменения в системе DNS по всему Интернету занимает больше времени. Если после добавления записей DNS возникла проблема с потоком обработки почты или другие неполадки, см. статью Устранение неполадок после смены имени домена или записей DNS.Typically it takes about 15 minutes for DNS changes to take effect. However, it can occasionally take longer for a change you’ve made to update across the Internet’s DNS system. If you’re having trouble with mail flow or other issues after adding DNS records, see Troubleshoot issues after changing your domain name or DNS records.

Изменение записей сервера доменных именChange your domain’s nameserver (NS) records

Когда вы доберется до последнего шага мастера настройки доменов в Microsoft 365, у вас остается одна задача.When you get to the last step of the domains setup wizard in Microsoft 365, you have one task remaining. Чтобы настроить домен с Microsoft 365 службами, например электронной почтой, вы измените записи имен домена (или NS) в регистраторе домена, чтобы указать на Microsoft 365 и вторичные имена.To set up your domain with Microsoft 365 services, like email, you change your domain’s nameserver (or NS) records at your domain registrar to point to the Microsoft 365 primary and secondary nameservers. Затем, Microsoft 365 в котором размещена DNS, для вас автоматически устанавливаются необходимые записи DNS для ваших служб.Then, because Microsoft 365 hosts your DNS, the required DNS records for your services are set up automatically for you. Вы можете самостоятельно обновлять записи сервера доменных имен, следуя инструкциям в разделе справки на веб-сайте регистратора доменных имен.You can update the nameserver records yourself by following the steps your domain registrar may provide in the help content at their website. Если вы еще не знакомы с DNS, обратитесь в службу поддержки регистратора доменных имен.If you’re not familiar with DNS, contact support at the domain registrar.

Чтобы самостоятельно изменить серверы доменных имен на веб-сайте регистратора доменных имен, выполните указанные ниже действия.To change your domain’s nameservers at your domain registrar’s website yourself, follow these steps:

Найдите область на веб-сайте регистратора домена, в которой можно изменить тезки для домена или области, в которой можно использовать настраиваемые именные имена.Find the area on the domain registrar’s website where you can change the nameservers for your domain or an area where you can use custom nameservers.
Создайте записи nameserver или отредактировать существующие записи nameserver, чтобы соответствовать следующим значениям:Create nameserver records, or edit the existing nameserver records to match the following values:
- Первый именник: ns1.bdm.microsoftonline.comFirst nameserver: ns1.bdm.microsoftonline.com
- Второй именник: ns2.bdm.microsoftonline.comSecond nameserver: ns2.bdm.microsoftonline.com
- Третий nameserver: ns3.bdm.microsoftonline.comThird nameserver: ns3.bdm.microsoftonline.com
- Четвертый именник: ns4.bdm.microsoftonline.comFourth nameserver: ns4.bdm.microsoftonline.com
Совет
Лучше всего добавить все четыре записи, но если регистратор поддерживает только две, добавьте ns1.bdm.microsoftonline.com и ns2.bdm.microsoftonline.com.It’s best to add all four records, but if your registrar only supports two, add ns1.bdm.microsoftonline.com and ns2.bdm.microsoftonline.com.
Сохраните изменения.Save your changes.

Внимание!

При изменении записей NS домена, указываю на Microsoft 365 имен, все службы, которые в настоящее время связаны с доменом, затронуты.When you change your domain’s NS records to point to the Microsoft 365 nameservers, all the services that are currently associated with your domain are affected. Если вы пропустили какие-либо этапы работы мастера, например добавление адресов электронной почты, или используете свой домен для размещения блогов, корзин для покупок или других служб, необходимо выполнить дополнительные действия.If you skipped any steps of the wizard, such as adding email addresses, or if you’re using your domain for blogs, shopping carts, or other services, there are additional steps that are required. В противном случае это изменение может привести к простою служб, например к отсутствию доступа к электронной почте или веб-сайту.Otherwise this change could result in service downtime, such as lack of email access or your current website being inaccessible.

Найдите на веб-сайте регистратора домена область, в которой можно изменить серверы доменных имен для вашего домена.Find the area on the domain registrar’s website where you can edit the nameservers for your domain.
Создайте две записи сервера доменных имен или измените существующие так, чтобы они соответствовали указанным ниже значениям.Create two nameserver records, or edit the existing nameserver records to match the following values:
- Первый nameserver: ns1.dns.partner.microsoftonline.cnFirst nameserver: ns1.dns.partner.microsoftonline.cn
- Второй именник: ns2.dns.partner.microsoftonline.cnSecond nameserver: ns2.dns.partner.microsoftonline.cn
Совет
Необходимо использовать по крайней мере две записи nameserver.You should use at least two nameserver records. Если в списке указаны другие имена, их можно либо удалить, либо изменить на ns3.dns.partner.microsoftonline.cn и ns4.dns.partner.microsoftonline.cn.If there are any other nameservers listed, you can either delete them, or change them to ns3.dns.partner.microsoftonline.cn and ns4.dns.partner.microsoftonline.cn.
Сохраните изменения.Save your changes.

Внимание!

При изменении записей NS вашего домена, чтобы указать на Office 365, выполняемые 21 nameserversVianet, все службы, которые в настоящее время связаны с вашим доменом, затронуты.When you change your domain’s NS records to point to the Office 365 operated by 21Vianet nameservers, all the services that are currently associated with your domain are affected. Если вы пропустили какие-либо этапы работы мастера, например добавление адресов электронной почты, или используете свой домен для размещения блогов, корзин для покупок или других служб, необходимо выполнить дополнительные действия.If you skipped any steps of the wizard, such as adding email addresses, or if you’re using your domain for blogs, shopping carts, or other services, there are additional steps that are required. В противном случае это изменение может привести к простою служб, например к отсутствию доступа к электронной почте или веб-сайту.Otherwise this change could result in service downtime, such as lack of email access or your current website being inaccessible.

Например, для размещения электронной почты и веб-сайта может понадобиться выполнить дополнительные действия.For example, here are some additional steps that might be required for email and website hosting:

Перед изменением записей NS переместите все адреса электронной почты, Microsoft 365 домена.Move all email addresses that use your domain to Microsoft 365 before you change your NS records.
Хотите добавить домен, который в настоящее время используется с веб-адресом, например www.fourthcoffee.com?Want to add a domain that’s currently used with a website address, like www.fourthcoffee.com? При добавлении домена можно сделать следующие действия, чтобы сохранить веб-сайт, на котором сейчас находится сайт, чтобы люди могли по-прежнему получать доступ к веб-сайту после изменения записей NS домена, чтобы указать на Microsoft 365.You can take below steps while you add the domain to keep its website hosted where the site is hosted now so people can still get to the website after you change the domain’s NS records to point to Microsoft 365.

В Центре администрирования перейдите на страницу Settings (Параметры) > Domains (Домены).In the admin center, go to the Settings > Domains page.
На странице Домены выберите домен.On the Domains page, select a domain.
На странице сведения о домене выберите вкладку записей DNS.On the domain details page, select the DNS records tab.
Выберите запись Добавить.Select Add record.
В пользовательской области записи DNS из списка выпаданий типа выберите A (Address).In the Add a custom DNS record pane, from the Type dropdown list, select A (Address).
В поле Имя хозяина или псевдоним введите @ .In the Host name or Alias box, type @.
В поле IP-адрес введите статичный IP-адрес веб-сайта, на котором он в настоящее время находится.In the IP Address box, type the static IP address for the website where it’s currently hosted. Например, 172.16.140.1.For example, 172.16.140.1.
Важно!
Это должен быть статичный IP-адрес для веб-сайта, а не динамический IP-адрес.This must be a static IP address for the website, not a dynamic IP address. Чтобы убедиться, что вы можете получить статичный IP-адрес для общедоступных веб-сайтов, ознакомьтесь с сайтом, на котором размещен ваш веб-сайт.To make sure you can get a static IP address for your public website, check with the site that hosts your website.
Если вы хотите изменить параметр TTL для записи, выберите новое время из списка отсевов TTL.If you want to change the TTL setting for the record, select a new length of time from the TTL dropdown list. В противном случае продолжайте шаг 9.Otherwise, continue to step 9.
Нажмите кнопку Сохранить.Select Save.

Кроме того, можно создать запись CNAME, чтобы упростить поиск веб-сайта.In addition, you can create a CNAME record to help customers find your website.

Выберите запись Добавить.Select Add record.
В пользовательской области записи DNS из списка выпаданий типа выберите CNAME (Alias).In the Add a custom DNS record pane, from the Type dropdown list, select CNAME (Alias).
В поле Имя хозяина или псевдоним введите www.In the Host name or Alias box, type www.
В поле Пункты для адреса введите полное доменное имя (FQDN) для вашего веб-сайта.In the Points to address box, type the fully qualified domain name (FQDN) for your website. Например, contoso.5om.For example, contoso.5om.
Если вы хотите изменить параметр TTL для записи, выберите новое время из списка отсевов TTL.If you want to change the TTL setting for the record, select a new length of time from the TTL dropdown list. В противном случае продолжайте шаг 6.Otherwise, continue to step 6.
Нажмите кнопку Сохранить.Select Save.

После обновления записей имен, чтобы указать на Microsoft, настройка домена завершена.After the nameserver records are updated to point to Microsoft, your domain setup is complete. Электронная почта отправлена в Корпорацию Майкрософт, и трафик на ваш веб-сайт продолжает переходить на текущий веб-сайт.»Email is routed to Microsoft, and traffic to your website address continues to go to your current website host.`

Примечание

Your nameserver record updates may take up to several hours to update across the Internet’s DNS system.Your nameserver record updates may take up to several hours to update across the Internet’s DNS system. Затем ваша электронная почта Майкрософт и другие службы будут настроены на работу с доменом.Then your Microsoft email and other services will be all set to work with your domain.

См. также:Related content

Добавление записей DNS для подключения домена (статьи)Add DNS records to connect your domain (article)
Поиск и устранение неполадок после добавления домена и записей DNS (статья)Find and fix issues after adding your domain or DNS records (article)
Управление доменами (страница ссылки)Manage domains (link page)

Управление ресурсными DNS-записями домена в Cloudflare

Ресурсные DNS-записи включают в себя информацию о доменной зоне: A-запись, AAAA-запись, NS-запись, MX-запись, TXT-запись, SRV-запись, CNAME-запись.

Для создания новой записи перейдите в Инструменты → Cloudflare → DNS-записи и нажмите кнопку «Создать».

Заполните поля:

Имя — поддомен, для которого будет создана запись
TTL — время в секундах, в течение которого данные о ресурсной записи будут храниться в кэше

Выберите тип ресурсной записи:

A-запись — определяет IPv4-адрес, который соответствует доменному имени. При включении проксирования трафик для домена, указанного в поле «Имя», будет направляться через сервис Cloudflare
AAAA-запись — определяет IPv6-адрес, который соответствует доменному имени. При включении проксирования трафик для домена, указанного в поле «Имя», будет направляться через сервис Cloudflare
NS-запись — доменное имя DNS-сервера для домена. Может содержать несколько серверов, включая первичный (master). Для настройки NS-записи укажите домен DNS-сервера
MX-запись — применяется для маршрутизации почты в сети (определяет адрес почтового шлюза и приоритет). Для настройки MX-записи укажите:
домен — поддомен доменной зоны, который является почтовым шлюзом
приоритет — чем больше число, тем ниже приоритет
TXT-запись — используется только теми протоколами, для которых это необходимо. Укажите текстовое значение в поле «Значение»
SRV-запись — определяет имя хоста и порт сервера домена, позволяет использовать несколько серверов для одного домена. Для настройки SRV-записи укажите:
домен — тот, к которому относится ресурсная запись
приоритет — чем больше число, тем ниже приоритет
вес — если у серверов одинаковый приоритет, то первым будет отправлен запрос к серверу с большим весом (если с определённым значением приоритета только один сервер, то для него вес должен быть указан равным 0)
порт — порт сервера, на который будет отправлен запрос
CNAME-запись — позволяет перенаправить запрос к доменному имени-псевдониму, если оно не имеет других ресурсных записей. Для настройки CNAME-записи укажите домен, на который будет перенаправляться запрос. При включении проксирования трафик для домена, указанного в поле «Имя», будет направляться через сервис Cloudflare

Не забудьте применить изменения!

Управлять записями DNS | Домены

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

Ваш домен зарегистрирован в GoDaddy и использует наши DNS-серверы. В этом случае вы будете настраивать DNS в своем аккаунте GoDaddy.
Ваш домен не зарегистрирован в GoDaddy, но использует наши DNS-серверы. В этом случае вы тоже будете настраивать DNS в своем аккаунте GoDaddy. Обычно так происходит, если ваш веб-сайт размещен у нас или вы используете хостинг DNS.
Ваш домен зарегистрирован в другой компании и не использует наши DNS-серверы. В этом случае вы будете настраивать DNS не у нас, а в компании, где размещена ваша DNS и/или веб-сайт.

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

Запись A. Главная запись DNS, связывающая ваш домен с IP-адресом, который приводит посетителей на ваш веб-сайт. Добавить / Изменить / Удалить
Поддомен: Любая запись DNS, используемая в качестве префикса вашего доменного имени, например blog.coolexample.com. Поддомен можно создать с помощью записи A, которая указывает на IP-адрес (самый распространенный вариант), записи CNAME, которая указывает на URL, или даже с помощью записи MX. Добавить / Изменить / Удалить
Запись CNAME. Эта запись также выступает префиксом доменного имени и иногда может считаться поддоменом. Запись CNAME не может указывать на IP-адрес, а только на другое доменное имя или URL. Например, вы можете создать запись CNAME для домена store.coolexample.com, которая указывает на другой URL, допустим на магазин, созданный на платформе Shopify. Добавить / Изменить / Удалить
Запись MX. Управляет вашим адресом электронной почты. Благодаря ей письма попадают в ваш почтовый ящик. Разные почтовые сервисы используют разные записи MX. В почте GoDaddy эти записи настраиваются автоматически. Добавить / Изменить / Удалить
Запись TXT. Позволяет подтвердить право собственности на домен и настроить правила для отправителей писем. Добавить / Изменить / Удалить
Запись SPF: Тип записи TXT, позволяющей настраивать правила для отправителей писем. Это дополнительный тип записи DNS. Добавить / Изменить / Удалить
Запись NS. Содержит сведения о ваших DNS-серверах. Используйте эти записи, чтобы понять, какие DNS-серверы вам нужно использовать, если ваш домен не зарегистрирован в GoDaddy, но вы хотите настраивать DNS у нас. Это дополнительный тип пользовательской записи DNS. Добавить / Изменить / Удалить

Другие действия

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

Статьи по теме

Помощь: Домены: DNS-записи

Cистема доменных имен (DNS) – это распределенная база данных, в которой хранится информация о доменах: ip-адреса домена, ns-сервера, обслуживающие домен, mx-записи для этого домена и другая служебная информация.

Информация о домене хранится в виде записей. Основные типы записей:

1. SOA-запись – содержит имя первичного ns-сервера для этой зоны, e-mail администратора этой зоны, серийный номер, значения времени кеширования для всех записей зоны по умолчанию.
Для создания SOA-записи (поднятия зон на домен) необходимо добавить домен через раздел «Перенос домена» в личном кабинете.

2. NS-запись указывает на DNS-cервер для данного домена. Например, наши NS-записи:

ns1.valuehost.ru
ns2.valuehost.ru
ns3.valuehost.ru

Через панель управления хостингом в Вашем личном кабинете Вы можете задать/изменить NS-записи только для поддоменов. Сменить NS-записи для основного домена можно через регистратора либо по запросу в «Поддержку онлайн».

3. А- и CNAME-записи.

А–запись связывает имя хоста с ip-адресом.
CNAME-запись или каноническая запись имени используется для перенаправления на другое имя.
Обе эти записи можно изменить в панели управления хостингом в разделе DNS — Alias. При задании/изменении А — записи в поле «Адрес» вводится IP-адрес;
Пример: 217.112.ХХ.ХХ
При задании/изменении CNAME-записи – каноническое имя с точкой на конце.
Пример: test.example.ru.
4. MX-запись
Указывает на серверы, принимающие почту для данного домена. MX-запись состоит из двух фрагментов данных: приоритета (чем меньше число, тем выше приоритет) и доменного имени (почтового сервера).
Изменить эту запись можно также в разделе DNS (MX). Доменное имя в поле «Адрес» всегда прописывается с точкой на конце.
Например: mail.example.ru.
5. SRV- и TXT-записи.
SRV – записи указывают месторасположение серверов для различных сервисов.
SRV запись состоит из следующих частей:
_service._proto.name TTL class SRV priority weight port target
service – имя сервиса. Например xmpp или sip.
proto – имя протокола. Обычно tcp или udp.
name – имя домена, в котором размещена данная служба.
class – стандарт DNS, поле класса
TTL – стандарт DNS, время жизни.
priority – приоритет записи. Чем меньше число, тем выше приоритет
weight – вес записи. Используется для записей с одинаковым приоритетом
port – порт, на котором размещена указанная служба на данном сервере
hostname(target) – имя сервера.
TXT-записи используются для указания дополнительной текстовой информации.
Добавить и изменить SRV-, TXT-записи можно в разделе DNS (SRV, TXT) панели управления хостингом.
6. PTR-запись
Связывает IP хоста с его каноническим именем.
Используется для уменьшения объёма нежелательной почтовой корреспонденции. Многие серверы-получатели электронной почты проверяют наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Настраивается на стороне интернет-провайдера, предоставившего IP-адрес.
Все изменения ДНС настроек, сделанные в Вашей панели управления, будут иметь силу только для доменов делегированных на наши NS-сервера.
Если какие-либо записи меняются для основного домена, например example.ru, то поле «Название» необходимо оставить пустым, если вводится какое-либо значение, например 1, то настройки применятся для поддомена 1.example.ru
Что такое DNS-записи домена?
Система доменных имен (DNS) — это адресная книга интернета. DNS направляет трафик на сайт почту, сопоставляя доменные имена с IP-адресами. В этом руководстве рассматриваются основные концепции DNS и DNS- записей.
Общая группа доменов указывается справа. В приведенных ниже примерах домен верхнего уровня или TLD — это .com.
example.com mail.hello.example.com
Каждое значение слева от TLD отделяется точкой, и называются поддоменами. hello и mail соответственно являются поддоменами второго и третьего уровня. Субдомены используются для идентификации определенных компьютеров или служб.
Выбор и указание сервера DNS является неотъемлемой частью владения доменом. Иначе клиентские устройства не будут знать, где найти информацию о DNS.
Серверы имен размещают информацию о домене DNS в текстовом файле, который называется файлом зоны. Они также известны как записи Start of Authority (SOA). Вы можете разместить свою информацию DNS на серверах имен в одном из нескольких мест:
Регистратор домена;
Ваш собственный DNS-сервер;
Сторонний DNS-хостинг.
Записи DNS сопоставляют доменные имена с IP-адресами. Затем DNS-записи автоматически объединяются в файл зоны, что позволяет подключенным устройствам искать правильный IP-адрес домена. Если вы решите использовать серверы имен Linode, диспетчер DNS поможет создать файл зоны. Он содержит следующие записи:
; example.com [448369] $TTL 86400 @ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400 @ NS ns1.linode.com. @ NS ns2.linode.com. @ NS ns3.linode.com. @ NS ns4.linode.com. @ NS ns5.linode.com. @ MX 10 mail.example.com. @ A 12.34.56.78 mail A 12.34.56.78 www A 12.34.56.78
Файл зоны каждого домена включает в себя адрес электронной почты администратора домена, серверы имен и DNS-записи. Вы можете создавать множество записей для любого количества поддоменов.
Доменное имя должно быть переведено на IP-адрес. DNS сопоставляет понятные пользователю доменные имена (example.com) с IP-адресами (192.0.2.8). Это происходит в специальном текстовом файле, называемом файлом зоны. В нем перечислены домены и соответствующие им IP-адреса. Файл зоны похож на телефонную книгу, в которой имена совпадают с адресами улиц.
Вот как работает процесс поиска DNS:
Вы вводите доменное имя, например com,в адресную строку браузера.
Компьютер подключен к интернету через провайдера (ISP). DNS-преобразователь интернет-провайдера запрашивает у корневого сервера имен соответствующий сервер имен TLD.
Корневой DNS-сервер отвечает IP-адресом для сервера имен .com.
DNS-распознаватель провайдера использует IP-адрес, полученный от корневого сервера имен.
Сервер имен .comотвечает IP-адресом сервера имен com.
DNS-распознаватель ISP считывает файл зоны с сервера имен домена.
Файл зоны показывает, какой IP-адрес соответствует домену.
Теперь, когда у провайдера есть IP-адрес для com, он возвращает его браузеру, который затем обращается к серверу сайта.
Описанный выше сценарий выполняется, если у провайдера нет информации о запрашиваемом домене. На самом деле провайдеры кэшируют данные о DNS после того, как получили ее в первый раз. Это ускоряет поиск и снижает нагрузку на DNS-серверы.
Но кэширование может стать проблемой, если вы недавно внесли изменения в информацию о DNS. Для ее решения измените значение времени жизни файла зоны (TTL), чтобы обновление DNS происходило быстрее.
Запись A связывает домен или субдомен с IP-адресом, что позволяет трафику достигать сайта. Это основная функция DNS. Типичная запись A выглядит следующим образом:
example.com A 12.34.56.78 hello.example.com A 12.34.56.78
Вы можете указать разные субдомены на разных IP-адресах. Если нужно указать каждый субдомен example.com на IP, то можете использовать для субдомена звездочку (*):
*.example.com A 12.34.56.78
Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:
Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:
Запись AXFR используется для репликации DNS. Хотя существуют более современные способы.
Записи AXFR не используются в обычных файлах зон. Чаще всего они применяются на подчиненном DNS-сервере для репликации файла зоны с главного DNS-сервера.
DNS Certification Authority Authorization (CAA) использует DNS, чтобы владелец домена мог указать, каким центрам сертификации разрешено выдавать сертификаты для этого домена.
Запись CNAME (запись канонического имени) соответствует домену или поддомену. При записи CNAME используются разрешения DNS целевого домена в качестве разрешения псевдонима. Например:
alias.com CNAME example.com. example.com A 12.34.56.78
При запросе alias.com начальный поиск DNS найдет запись CNAME с целью example.com. Будет запущен новый поиск DNS example.com, который найдет IP-адрес 12.34.56.78. Посетители alias.com будут направлены к IP-адресу 12.34.56.78.
Записи CNAME применяются, чтобы домены могли иметь псевдонимы. Некоторые почтовые серверы странным образом обрабатывают почту для доменов с записями CNAME. Поэтому не следует использовать запись CNAME для домена, который принимает электронную почту.
Записи MX не могут ссылаться на имена хостов, определенные CNAME. Целевой домен для записи CNAME также должен иметь нормальное разрешение A-записи.
Примечание
CNAME-запись может быть эффективным способом перенаправления трафика от одного домена к другому, сохраняя тот же URL-адрес. Но она не работает так же, как редирект URL-адресов. CNAME-запись направляет трафик для определенного домена на IP-адрес целевого домена. Как только пользователь достигнет этого IP-адреса, конфигурация сервера будет определять способ обработки домена. Если этот домен не настроен, сервер отобразит веб-страницу по умолчанию. Она может быть веб-страницей целевого домена в записи CNAME, в зависимости от того, как настроен сервер.
Запись DKIM она же запись DomainKeys Identified Mail отображает открытый ключ для аутентификации сообщений, которые подписаны с помощью протокола DKIM. Это расширяет возможности проверки подлинности электронной почты. Типичная запись DKIM выглядит следующим образом:
selector1._domainkey.example.com TXT k=rsa;p=J8eTBu224i086iK
DKIM-записи представлены в виде текстовых записей. Запись должна быть создана для субдомена, который имеет уникальный селектор для этого ключа, затем указывается точка (.) и _domainkey.example.com. Тип -TXT, значение включает в себя тип ключа, за которым следует фактический ключ.
Запись MX устанавливает адресат доставки почты для домена или субдомена. Типичная MX-запись выглядит следующим образом:
example.com MX 10 mail.example.com. mail.example.com A 12.34.56.78
Приведенные выше записи направляют почту для example.com на сервер mail.example.com. В идеале MX-запись должна указывать на домен, который также является именем хоста его сервера. Если вы используете стороннюю почтовую службу, такую как Google Apps, то следует применять предоставленные ими MX-записи.
Приоритет является еще одним компонентом MX-записей. Это число, записанное между типом записи и целевым сервером. В примере, приведенном выше, использован приоритет 10.
Приоритет позволяет назначить резервный почтовый сервер (или серверы) для определенного домена. Меньшие числа имеют более высокий приоритет. Пример домена, который имеет два резервных почтовых сервера:
example.com MX 10 mail_1.example.com example.com MX 20 mail_2.example.com example.com MX 30 mail_3.example.com
Если mail_1.example.com не работает, электронная почта будет доставлена на mail_2.example.com. Если mail_2.example.com также не работает, почта будет доставлена на mail_3.example.com.
NS-записи устанавливают серверы имен для домена. Они задаются для домена у регистратора и в файле зоны. Типичные записи сервера имен выглядят следующим образом:
example.com NS ns1.linode.com. example.com NS ns2.linode.com. example.com NS ns3.linode.com. example.com NS ns4.linode.com. example.com NS ns5.linode.com.
Серверы имен, которые вы назначаете у своего регистратора, содержат файл зоны для домена.
Также можно настроить различные серверы имен для любого из поддоменов. Они задаются в файле зоны вашего основного домена:
mail.example.com NS ns1.nameserver.com mail.example.com NS ns2.nameserver.com
Первичные серверы имен настраиваются у регистратора, а вторичные — в файле зоны основного домена. Порядок NS- записей не имеет значения. DNS-запросы отправляются случайным образом на разные серверы. Если один хост не отвечает, будет запрошен другой.
Запись PTR или запись указателя сопоставляет IP-адрес с доменом или поддоменом, позволяя функционировать обратным DNS-запросам. Она работает противоположно записи A, в том смысле, что позволяет искать домен, связанный с конкретным IP-адресом, а не наоборот.
Записи PTR обычно устанавливаются на хостинге. Они не являются частью файла зоны домена.
Для добавления записи PTR необходимо создать действительную запись A или AAAA, которая указывает IP-адрес для нужного домена.
Примечание
Можно использовать разные IP-адреса (включая адреса IPv4 и IPv6), на которых один и тот же домен установлен для обратного DNS. Для этого необходимо настроить несколько записей A или AAAA для этого домена, которые указывают на различные IP-адреса.
Запись SOA обозначает файл зоны с именем хоста, на котором он был создан. Далее в нем указывается контактный адрес электронной почты администратора домена. Типичная запись SOA:
@ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400
Примечание
Адрес электронной почты администратора пишется с точкой (.) вместо символа @.
Вот что означают эти цифры:
Серийный номер: номер редакции файла зоны этого домена. Он изменяется, когда файл обновляется.
Время обновления: количество времени (в секундах), в течение которого вторичный DNS-сервер будет хранить файл зоны, прежде чем проверит изменения.
Время повтора: время, которое вторичный DNS-сервер будет ожидать, прежде чем повторить передачу файла зоны.
Время истечения: время, в течение которого вторичный DNS-сервер будет ожидать, прежде чем истечет срок действия текущей копии файла зоны, если он не сможет обновить себя.
Минимальный TTL: минимальный период времени, в течение которого другие серверы должны хранить в кэше данные из файла зоны.
Сервер имен, упомянутый в записи SOA, считается основным для динамического DNS. На нем изменения файла зоны производятся до того, как они распространяются на другие серверы имен.
Запись Sender Policy Framework (SPF) содержит список почтовых серверов, назначенных для домена или субдомена. Это помогает подтвердить легитимность почтового сервера и снижает вероятность подделки заголовков писем. Спамеры часто пытаются сделать это, чтобы обойти фильтры.
SPF- запись домена сообщает другим почтовым серверам, какие исходящие серверы являются допустимыми источниками электронной почты. Поэтому они могут отклонять поддельную почту с вашего домена, отправленную с неавторизованных серверов. Простая SPF-запись выглядит следующим образом:
example.com TXT "v=spf1 a ~all"
В SPF-записи необходимо перечислить почтовые серверы, с которых вы отправляете почту, а затем исключить остальные. Ваша SPF- запись будет содержать домен или поддомен, тип (TXT или SPF, если ваш сервер имен поддерживает его) и текст (который начинается с «v = spf1» и содержит настройки SPF- записи).
С помощью этой SPF-записи принимающий сервер проверит и IP-адрес отправляющего сервера, и IP-адрес example.com.
Примечание
Убедитесь, что SPF- записи не слишком строгие. Если вы случайно исключите легитимный почтовый сервер, полученные от него письма могут быть помечены как спам.
Рекомендуем посетить ресурс openspf.org, чтобы узнать, как работают SPF- записи и как создать запись, которая подходит для вашей настройки.
Запись SRV сопоставляет конкретную службу, работающую на домене или поддомене, с целевым доменом. Это позволяет направлять трафик, предназначенный для определенных служб, на другой сервер. Типичная запись SRV:
_service._protocol.example.com SRV 10 0 5060 service.example.com
Описание элементов, которые используются в SRV-записи:
Служба: названию службы должно предшествовать подчеркивание ( _ ) и точка ( . ). Служба может быть чем-то вроде _xmpp.
Протокол: имя протокола должно начинаться с подчеркивания ( _ ) и заканчиваться точкой ( . ). Протокол может быть чем-то вроде _tcp.
Домен: имя домена, который будет получать исходный трафик для службы.
Приоритет: первое число (10 в приведенном выше примере) позволяет установить приоритет для целевого сервера. Можно установить цели с разными приоритетами, что позволит иметь резервный сервер (или серверы) для этой службы. Меньшие числа имеют более высокий приоритет.
Вес: Если две записи имеют одинаковый приоритет, вместо него учитывается вес.
Порт: порт TCP или UDP, на котором работает служба.
Цель: целевой домен или поддомен. Он должен иметь запись A или AAAA, которая разрешается в IP-адресе.
Примером использования SRV-записей является настройка федеративной VoIP .
Запись TXT (текстовая запись) предоставляет информацию о домене другим интернет-ресурсам. Одно из распространенных применений TXT-записи — создание SPF- записи на серверах имен, которые изначально не поддерживают SPF. Другой вариант использования — создание записи DKIM для почты.
Данная публикация является переводом статьи «DNS Records: An Introduction» , подготовленная редакцией проекта.
записей сервера имен (NS) в Avi DNS
Начиная с версии 17.1.2, Avi DNS поддерживает записи сервера имен (NS) как часть статических записей DNS (Avi GSLB не поддерживает записи NS).
Запись DNS-сервера (NS) определяет доменное имя сервера имен, обслуживающего конкретный домен. Например, запись NS со временем жизни (TTL) 1100 секунд, а для домена com , обслуживаемого сервером имен a.gtld-servers.net , будет определен следующим образом:
com. 1100 IN NS a.gtld-servers.net.
Для записей NS Avi DNS может вести себя как авторитетный сервер, так и как неавторизованный сервер. Запись NS может быть настроена в Avi DNS для двух режимов домена DNS: делегированного и неделегированного.
Делегированные домены или вырезание зоны
Если желаемое поведение состоит в том, чтобы Avi DNS действовал как неавторизованный сервер для домена NS-записи, тогда NS-запись должна быть настроена с параметром делегирования, установленным на True .Делегирование указывает, что доменное имя для записи NS делегировано другому авторитетному серверу имен. То есть доменное имя для записи NS представляет собой вырезку зоны, при этом домены в этом домене принадлежат другому серверу имен. Например, xyz.foo.com — это зона, вырезанная для домена foo.com , при этом домены в пределах xyz.foo.com (также известного как * .xyz.foo.com ) управляются другим именем. сервер, чем тот, который управляет xyz.foo.com ).
Когда доменное имя настроено для вырезания зоны, обязательно настроить IP-адреса соответствующих серверов имен в записи NS, связанной с этим доменным именем. IP-адрес является обязательным, если домен сервера имен может привести к рекурсивному запросу DNS к этому доменному имени:
DNS-запрос для записи NS для домена: foo.com
Ответ содержит имя сервера: ns1.avi.com
Начиная с доменного имени ns1.foo.com должен быть разрешен, это приводит к запросу A для ns1.foo.com , что приводит к ответу с записью NS для ns1.foo.com (но без записи A, что приводит к запросу NS для ns1.foo.com снова и снова), что приводит к неопределенной рекурсии.
Чтобы избежать этой рекурсии, полное доменное имя для сервера имен в записи NS также настраивается с записью A (IP-адрес). Эта запись A называется связующей записью для записи NS. См. Пример ниже.
static_dns_records { fqdn: "avi.com" тип: DNS_RECORD_NS делегировано: правда wildcard_match: правда ttl: 1100 ns { nsname: "ns1.avi.com" айпи адрес { адрес: "192.5.6.30" тип: V4 } } ns { nsname: "ns2.avi.net" } }
Вышеупомянутая конфигурация статической NS-записи предназначена для домена «avi.com », в котором есть записи NS, указывающие на два сервера имен. Таким образом, любой DNS-запрос с поддоменом «avi.com», который приходит на этот сервер, будет обслуживаться записями NS в РАЗДЕЛЕ АВТОРИТЕТА ответа DNS. Этот ответ заставит рекурсивный преобразователь имен направить DNS-запрос на любой из двух серверов имен. Таким образом, запрос для записи A для www.avi.com получит ответ двух записей NS в ответе DNS вместе с связующей записью для ns1.avi.com в ДОПОЛНИТЕЛЬНОМ РАЗДЕЛЕ ответа.Затем рекурсивный преобразователь отправит тот же DNS-запрос на сервер имен ns1.avi.com или ns2.avi.net.
ПРИМЕЧАНИЕ. Если желаемое поведение состоит в том, чтобы перехватывать все запросы для доменных имен, содержащих «avi.com» в качестве поддомена, тогда вы должны установить для поля совпадения с подстановочными знаками значение «Истина», иначе только запросы для «avi.com» будут направляться на серверы имен. Если для «avi.com» установлено сопоставление с подстановочными знаками, любой запрос в форме * .avi.com (например, foo.avi.com, abc.xyz.avi.com и т. Д.) Будет направлен на настроенные серверы имен.Если сопоставление с подстановочными знаками не установлено, запрос к доменам в форме * .avi.com может быть успешным, а может и нет, в зависимости от того, настроены эти полные доменные имена или нет в DNS VS.
Ниже показан запрос раскопок для
запись (A, AAAA, CNAME, SRV и т. Д.)
в домен, содержащий делегированный домен «com» в качестве поддомена,
с набором подстановочных знаков, 13 серверов имен (от a.gtld-servers.net до m.gtld-servers.net) и
соответствующих записей клея.
Запрошенный домен sales.avi.com имеет поддомен com.
; << >> DiG 9.10.3-P4-Ubuntu << >> @ 10.90.91.62 sales.avi.com A ; (Найден 1 сервер) ;; глобальные параметры: + cmd ;; Получил ответ: ;; - >> HEADER << - код операции: QUERY, статус: NOERROR, id: 57472 ;; флаги: qr aa rd; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИТЕТ: 13, ДОПОЛНИТЕЛЬНО: 13 ;; ВНИМАНИЕ: рекурсия запрошена, но недоступна ;; РАЗДЕЛ ВОПРОСА: ; sales.avi.com. В ;; РАЗДЕЛ ВЛАСТИ: com.1100 IN NS a.gtld-servers.net. com. 1100 IN NS b.gtld-servers.net. com. 1100 IN NS c.gtld-servers.net. com. 1100 IN NS d.gtld-servers.net. com. 1100 IN NS egtld-servers.net. com. 1100 IN NS f.gtld-servers.net. com. 1100 IN NS g.gtld-servers.net. com. 1100 IN NS h.gtld-servers.net. com. 1100 IN NS i.gtld-servers.net. com. 1100 IN NS j.gtld-servers.net. com. 1100 IN NS k.gtld-servers.net. com. 1100 IN NS l.gtld-servers.net. com. 1100 IN NS m.gtld-servers.net. ;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ: a.gtld-servers.net. 1100 А 192.5.6.30 b.gtld-servers.net. 1100 А 192.33.14.30 c.gtld-servers.net. 1100 А 192.26.92.30 d.gtld-servers.net. 1100 IN A 192.31.80.30 egtld-servers.net. 1100 IN A 192.12.94.30 f.gtld-servers.net. 1100 А 192.35.51.30 g.gtld-servers.net. 1100 А 192.42.93.30 h.gtld-servers.net. 1100 А 192.54.112.30 i.gtld-servers.net. 1100 А 192.43.172.30 j.gtld-servers.net. 1100 А 192.48.79.30 k.gtld-servers.net.1100 IN A 192.52.178.30 l.gtld-servers.net. 1100 А 192.41.162.30 m.gtld-servers.net. 1100 А 192.42.93.30 ;; Время запроса: 0 мсек. ;; СЕРВЕР: 10.90.91.62 # 53 (10.90.91.62) ;; КОГДА: Пт, 26 мая, 14:55:20 PDT 2017. ;; РАЗМЕР MSG rcvd: 469
Неделегированные домены
Если желательно, чтобы Avi DNS действовал как полномочный сервер для NS-записи, тогда NS-запись не должна быть настроена с параметром делегирования, установленным на True .Делегирование указывает, что доменное имя для записи NS делегировано другому авторитетному серверу имен. См. Пример ниже.
static_dns_records { fqdn: "google.com" тип: DNS_RECORD_NS wildcard_match: правда ttl: 1100 ns { nsname: "ns1.google.com" айпи адрес { адрес: "192.5.6.30" тип: V4 } } ns { nsname: "ns2.google.com " айпи адрес { адрес: "192.33.14.30" тип: V4 } } ns { nsname: "ns3.google.com" айпи адрес { адрес: "192.26.92.30" тип: V4 } } ns { nsname: "ns4.google.com" айпи адрес { адрес: "192.31.80.30" тип: V4 } } }
Приведенная выше конфигурация статической NS-записи предназначена для домена «google.com », в котором есть записи NS, указывающие на четыре сервера имен. Для этих NS-записей Avi DNS является авторитетным сервером имен. Таким образом, любой DNS-запрос NS с доменом «google.com», который поступает на этот сервер, будет обслуживаться записями NS в РАЗДЕЛЕ ОТВЕТА DNS-ответа, а записи A для IP-адресов серверов имен будут обслуживаться в ДОПОЛНИТЕЛЬНОМ РАЗДЕЛЕ.
ПРИМЕЧАНИЕ. Если в поле совпадения с подстановочными знаками установлено значение True , но домен не делегирован, то любой DNS-запрос, соответствующий неделегированному домену, получит ответ NXDOMAIN.
Ниже показан запрос запроса dig из
.
любой тип (A, NS, CNAME, SRV и др.)
в домен google.com,
с включенным сопоставлением подстановочных знаков и
4 сервера имен (от ns1.google.com до ns4.google.com).
; << >> DiG 9.10.3-P4-Ubuntu << >> @ 10.90.91.63 google.com A ; (Найден 1 сервер) ;; глобальные параметры: + cmd ;; Получил ответ: ;; - >> HEADER << - код операции: QUERY, статус: NOERROR, id: 39235 ;; флаги: qr aa rd; ЗАПРОС: 1, ОТВЕТ: 4, АВТОРИТЕТ: 0, ДОПОЛНИТЕЛЬНО: 4 ;; ВНИМАНИЕ: рекурсия запрошена, но недоступна ;; РАЗДЕЛ ВОПРОСА: ;Google.com. В ;; ОТВЕТНАЯ ЧАСТЬ: google.com. 1100 IN NS ns1.google.com. google.com. 1100 IN NS ns2.google.com. google.com. 1100 IN NS ns3.google.com. google.com. 1100 IN NS ns4.google.com. ;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ: ns1.google.com. 1100 А 192.5.6.30 ns2.google.com. 1100 А 192.33.14.30 ns3.google.com. 1100 А 192.26.92.30 ns4.google.com. 1100 IN A 192.31.80.30 ;; Время запроса: 0 мсек. ;; СЕРВЕР: 10.90.91.63 # 53 (10.90.91.63) ;; КОГДА: Пт, 26 мая, 15:49:35 PDT 2017 ;; РАЗМЕР MSG rcvd: 164
Запрос на поиск информации любого типа (A, NS, CNAME, SRV и т. Д.) К домену, содержащему домен «google.com», с включенным подстановочным знаком, 4 сервера имен (от ns1.google.com до ns2. google.com) и соответствующие записи A всегда будут вызывать ответ NXDOMAIN:
; << >> Рис.9.10.3-P4-Ubuntu << >> @ 10.90.91.63 mail.google.com A ; (Найден 1 сервер) ;; глобальные параметры: + cmd ;; Получил ответ: ;; - >> HEADER << - код операции: QUERY, статус: NXDOMAIN, id: 42986 ;; флаги: qr aa rd; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИТЕТ: 0, ДОПОЛНИТЕЛЬНО: 0 ;; ВНИМАНИЕ: рекурсия запрошена, но недоступна ;; РАЗДЕЛ ВОПРОСА: ; mail.google.com. В ;; Время запроса: 0 мсек. ;; СЕРВЕР: 10.90.91.63 # 53 (10.90.91.63) ;; КОГДА: Пт, 26 мая, 16:56:25 PDT 2017 ;; РАЗМЕР MSG rcvd: 33
Какова роль NS-записей на вершине DNS-домена?
Идентификация подчиненных
NS-записи уровня Apex используются главным сервером для идентификации своих подчиненных.Когда данные на полномочном сервере имен изменяются, он сообщает об этом через сообщения DNS NOTIFY (RFC 1996) всем своим партнерам в этом списке. Эти серверы, в свою очередь, перезвонят с запросом на запись SOA (которая содержит серийный номер) и примут решение о том, следует ли загрузить более свежую копию этой зоны.
Эти сообщения можно отправлять на серверы, не указанные в разделе NS , но для этого требуются специфические для сервера директивы конфигурации (например, директива ISC BIND also-notify ).Записи вершины 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 ;; ОПТИЧЕСКАЯ ПСЕВДОЗЕКЦИЯ: ; EDNS: версия: 0, флаги :; UDP: 4096 ;; РАЗДЕЛ ВОПРОСА: ;пример.com. IN NS ;; РАЗДЕЛ ВЛАСТИ: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ: a.iana-servers.net. 172800 IN A 199.43.135.53 a.iana-servers.net. 172800 В АААА 2001: 500: 8f :: 53 b.iana-servers.net. 172800 IN A 199.43.133.53 b.iana-servers.net. 172800 IN AAAA 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 ;; ОПТИЧЕСКАЯ ПСЕВДОЗЕКЦИЯ: ; EDNS: версия: 0, флаги :; UDP: 4096 ;; РАЗДЕЛ ВОПРОСА: ; example.com. IN NS ;; ОТВЕТНАЯ ЧАСТЬ: пример.com. 86400 IN NS a.iana-servers.net. example.com. 86400 IN NS b.iana-servers.net.
Тем не менее, эта связь может быть очень запутанной, поскольку невозможно узнать об авторитетных версиях этих записей NS без неавторизованных записей NS , определенных на родительской стороне перехода. Что произойдет, если они не согласятся?
Короткий ответ - «непоследовательное поведение».
Длинный ответ заключается в том, что серверы имен изначально будут заглушать все ссылки (и склеивать) в пустой кеш, но эти записи NS , A и AAAA могут в конечном итоге быть заменены при обновлении.Обновления происходят по мере истечения срока жизни этих временных записей или когда кто-то явно запрашивает ответ для этих записей.
A и AAAA записи для данных вне зоны (т.е. серверы имен com , определяющие связующее звено для данных вне зоны com , например example.net ) обязательно будут обновлены, поскольку Это хорошо известная концепция, согласно которой сервер имен не должен считаться авторитетным источником такой информации.(RFC 2181)
Когда значения записей NS различаются между родительской и дочерней сторонами реферала (например, серверы имен, введенные в панель управления регистратора, отличаются от записей NS , которые находятся на тех же серверах), наблюдаемое поведение будет несогласованные, вплоть до дочерних NS записей включительно полностью игнорируются. Это связано с тем, что поведение не совсем четко определено стандартами, а реализация варьируется в зависимости от различных рекурсивных реализаций сервера.Другими словами, согласованного поведения в Интернете можно ожидать только в том случае, если определения сервера имен для домена согласованы между родительской и дочерней сторонами перехода .
Короче говоря, рекурсивные DNS-серверы по всему Интернету будут возвращаться между получателями, если записи, определенные на родительской стороне реферала, не согласуются с официальными версиями этих записей. Первоначально данные, представленные в обращении, будут предпочтительнее, но будут заменены авторитетными определениями.Поскольку кеши постоянно перестраиваются с нуля по всему Интернету, Интернет не может рассчитывать на единственную версию реальности с такой конфигурацией. Если авторитетные записи делают что-то незаконное в соответствии со стандартами, например, указывают записи NS на псевдонимы, определенные CNAME , это становится еще более трудным для устранения неполадок; домен будет чередоваться между работающим и сломанным для программного обеспечения, которое отклоняет нарушение. (т.е. ISC BIND / с именем)
RFC 2181 §5.4.1 предоставляет таблицу ранжирования для надежности этих данных и четко указывает, что данные кэша, связанные с отсылками и связями, не могут быть возвращены в качестве ответа на явный запрос записей, на которые они ссылаются.
5.4.1. Данные рейтинга При рассмотрении вопроса о принятии RRSet в ответ или сохранении RRSet уже находится в кэше, сервер должен учитывать относительная вероятная достоверность различных данных. An авторитетный ответ из ответа должен заменить кешированные данные, в которых было получено из дополнительной информации в более раннем ответе.Однако дополнительная информация из ответа будет проигнорирована, если cache содержит данные из авторитетного ответа или файла зоны. Точность имеющихся данных предполагается из их источника. Надежность должна быть в порядке от наибольшего к наименьшему: + Данные из файла первичной зоны, кроме данных склеивания, + Данные с зоны передачи, кроме клея, + Авторитетные данные, включенные в раздел ответов авторитетный ответ. + Данные из авторитетного раздела авторитетного ответа, + Клей из первичной зоны, или клей из зонной передачи, + Данные из раздела ответов неавторитетного ответа, и неавторитетные данные из раздела ответов авторитетных ответы, + Дополнительная информация из авторитетного ответа, Данные из авторитетного раздела неавторитетного ответа, Дополнительная информация из неавторитетных ответов.<снип> Неаутентифицированные записи RR получены и кэшированы от наименее надежного из эти группировки, то есть данные из раздела дополнительных данных, и данные из авторитетного раздела неавторитетного ответа, должны не кэшироваться таким образом, чтобы они когда-либо были возвращены как ответы на полученный запрос. Их можно вернуть в качестве дополнительных информация при необходимости. Игнорирование этого позволит повышать надежность относительно ненадежных данных без причины или оправдания.
Система доменных имен
- установка различных записей NS как авторитетных в авторитетном DNS
Здесь действительно задаются два вопроса, и они прямо противоречат друг другу:
как мне дать указание DNS-серверам продолжить запрос к Amazon в качестве уполномоченного для домена без изменения записей DNS в регистраторе?
как мне сказать DNS-серверам получать запросы с серверов Amazon и НЕ останавливаться на QuickRouteDNS.COM?
Каждое делегирование в иерархии DNS должно быть более конкретным, чем предыдущее. Другими словами, вы можете делегировать поддомены, но вы не можете повторно делегировать то же имя, которое было делегировано вашему серверу. Правильное решение - изменить конфигурацию на уровне регистратора, чего вы пытаетесь избежать.
То, что у вас сейчас есть, - это распространенная неправильная конфигурация, известная как неполноценное делегирование (несоответствие записей NS), которая создает неверное впечатление, что такая конструкция достижима.Ниже приводится объяснение того, что происходит, но будет сложно проследить за ним, не разбираясь в концепциях DNS. Если я потеряю вас, примите как должное, что исправление данных регистратора - это правильный способ решения вашей проблемы.
Вот два примера фрагментов зоны:
$ ORIGIN example.com @ 2941 В SOA ns1.example.com. something.example.com. ( 2015071001; серийный 7200; обновить (2 часа) 900; повторить попытку (15 минут) 7200000; истекает (11 недель 6 дней 8 часов) 3600; минимум (1 час) ) @ IN NS ns1 @ IN NS ns2 sub IN NS ns1.contoso.com. sub IN NS ns2.contoso.com.
На серверах имен contoso.com:
$ ORIGIN sub.example.com. @ 2941 В SOA ns1.sub.example.com. something.contoso.com. ( 2015071001; серийный 7200; обновить (2 часа) 900; повторить попытку (15 минут) 7200000; истекает (11 недель 6 дней 8 часов) 3600; минимум (1 час) ) @ IN NS bagel.contoso.com. @ IN NS сало.contoso.com.
Какие записи NS в двух указанных выше зонах являются авторитетными для sub.example.com ? Если вы подумали, что это ns1 и ns2.contoso.com , вы ошиблись. Вопреки распространенному мнению, сервер имен, который выполняет делегирование, не считается авторитетным для записей NS , используемых для определения этого делегирования. Авторитетное определение: вместо принадлежит зоне на принимающей стороне делегирования.
Мы установили, что бекон и бублик являются официальными. Что здесь не так очевидно, так это то, что именователи не обязательно поймут это сразу. За делегированием следят добросовестно, и изначально предполагается, что серверы, получающие делегирование, являются авторитетными. Повреждение мозга происходит только тогда, когда эти записи NS обновляются. Обновления могут быть вызваны любым количеством вещей, от TTL делегирования NS записей, истекающих до явного запроса значения этих NS записей.После перезаписи записей NS используются новые серверы.
Собирая все вместе, есть начальный период, когда используются серверы имен, определенные вашим регистратором, за которым следует период, когда используется второй набор серверов имен. В течение первого периода любые записи, существующие только на втором наборе серверов, не будут работать. Во время второго периода любые записи, существующие только на первом наборе серверов, не будут работать.
Может показаться, что проблема в конечном итоге решится сама собой (просто подождите, пока все обновится), но этого никогда не произойдет.Люди перезапустят свои серверы имен, очистят кеш или установят новые серверы имен. Ваш домен будет существовать в несогласованном состоянии потока до тех пор, пока записи NS не станут согласованными. Гуру DNS могут делать с этим некоторые интересные вещи, но допустимые варианты использования этого типа конфигурации немногочисленны и далеки друг от друга. Среднестатистический пользователь должен любой ценой избегать противоречивых определений серверов имен.
Что такое записи NS и почему они важны для DNS
Запись NS или (запись сервера имен) сообщает рекурсивным серверам имен, какие серверы имен являются полномочными для зоны.Рекурсивные серверы имен просматривают записи NS, чтобы решить, кого спрашивать следующим при разрешении имени.
Вы можете иметь столько NS-записей, сколько хотите в вашем файле зоны. Преимуществом наличия нескольких записей NS является избыточность вашей службы DNS. Важно отметить, что для максимальной избыточности ваших NS-записей они должны размещаться в разных сегментах сети. Если они не размещены в разных сегментах сети и сеть выходит из строя, ваш DNS отключается.Ознакомьтесь с No-IP Plus Managed DNS, если вы заинтересованы в избыточности и надежности своего домена.
Записи
NS помогают обеспечить постоянную доступность всех доменов на вашем сервере. Множественные записи NS гарантируют, что ваши клиенты смогут без проблем заходить на ваш сайт каждый раз, даже если один или несколько ваших серверов имен недоступны. (Опять же, только если они размещены в разных сегментах сети.)
Примером этого является то, что если ваш бизнес расположен в районе, пострадавшем от стихийного бедствия, и ваши веб-серверы в этом месте не работают, ваши записи NS будут указывать на дополнительный сервер имен, который размещен в другом месте (где мать-природа имеет не сеять хаос), и клиенты по-прежнему могут добраться до вашего сайта и никогда не заподозрят, что что-то не так.
Еще один отличный пример: если ваш веб-сайт подвергся атаке DDoS (распределенный отказ в обслуживании), весь ваш веб-сайт не будет отключен. Трафик будет направлен в другое расположение сервера имен, имеющее резервную копию первичного сервера имен.
См. Следующий пример записей NS для No-IP.com
no-ip.com. 73002 IN NS ns1.no-ip.com. no-ip.com. 73002 IN NS ns2.no-ip.com. no-ip.com. 73002 IN NS ns3.no-ip.com. no-ip.com. 73002 IN NS ns4.no-ip.com. no-ip.com. 73002 IN NS ns5.no-ip.com. no-ip.com. 73002 IN NS ns1.no-ip.com.
Ознакомьтесь с частями 1 и 3 из этой серии:
Анатомия файла зоны DNS: запись SOA
Анатомия файла зоны DNS, часть третья: записи MX
Вопросы или комментарии? Пожалуйста, оставьте их ниже.
NS-Records (авторитетный сервер имен)
NS-записи идентифицируют DNS-серверы, ответственные (полномочные) за зону.
Зона должна содержать по одной NS-записи для каждого из собственных DNS-серверов (первичного и вторичного).
В основном используется для передачи зон (уведомляющих сообщений).
Эти NS-записи имеют то же имя, что и зона, в которой они расположены.
Более важной функцией NS-записи является делегирование.
Делегирование означает, что часть домена делегируется другим DNS-серверам.
Например, все суб-имена ".com" (например, "example.com ") делегированы из зоны com.
Зона com содержит NS-записи для всех подименов .com (очень много!).
Таким же образом можно делегировать суб-имена своего собственного доменного имени (например, «subname.example.com») другим DNS-серверам.
Чтобы делегировать "subname.example.com", создайте NS-записи для "subname.example.com" в зоне "example.com".
Эти NS-записи должны указывать на DNS-сервер, ответственный за «subname.example.com», например, «ns1.subname».example.com "- или DNS-сервер в другом месте, например" ns1.othername.net ".
NS-запись идентифицирует имя DNS-сервера, а не IP-адрес.
Из-за этого важно, чтобы существовала A-запись для указанного DNS-сервера (не обязательно на вашем DNS-сервере, но где бы она ни была), в противном случае может не быть никакого способа подключиться к этому DNS-серверу.
Если NS-запись делегирует под-имя («subname.example.com») DNS-серверу с именем в этом под-имени («ns1.subname.example.com "), A-запись для этого сервера (" "ns1.subname.example.com") должна существовать в родительской зоне ("example.com").
Эта A-запись называется «связующей записью», потому что на самом деле она не принадлежит родительской зоне, но необходима для определения местоположения DNS-сервера для делегированного под-имени.
Чтобы создать новую NS-запись, щелкните правой кнопкой мыши зону в левом списке в окне DNS Records и выберите «Новая NS-запись» во всплывающем меню.
Этот тип записи определен в RFC1035.
NS Record - Хостинг Википедия
Запись NS (запись сервера имен) имеет решающее значение для правильного функционирования доменных имен. Такие записи используются для идентификации имен DNS-серверов и, как следствие, обеспечивают доступность запрошенного доменного имени. Каждый раз, когда вы переключаетесь на нового поставщика услуг хостинга, вам необходимо переключать записи NS - это может занять до 24 часов, потому что изменение записи NS должно распространяться по Интернету. Вы можете контролировать свое доменное имя благодаря специальным услугам, предоставляемым регистраторами доменов и компаниями, предоставляющими веб-хостинг, включая управление DNS и управление WHOIS.
WHOIS имеет относительно ограниченные масштабы, поскольку на самом деле он служит только для того, чтобы помочь установить, кто действительно владеет доменом, и даже в этом случае многие владельцы доменов предпочитают скрывать свои настоящие данные, чтобы данные WHOIS не были точными. Это просто формальная часть процесса регистрации домена. С другой стороны, настраиваемые записи DNS относятся к высокофункциональной области управления доменными именами, а настраиваемый DNS действительно является ключом к доступности интернет-сервисов и их поведению.
Краткий обзор записей NS
Веб-хосты и регистраторы доменов обычно позволяют клиентам редактировать записи NS для своего домена, это самая основная функциональность доменных имен, поскольку записи NS (или сервера имен) являются поддерживающим слоем для DNS (системы доменных имен). Записи NS хранятся в файлах зоны DNS. Файлы зоны позволяют пользователям обращаться к записям для преобразования доменных имен в IP-адреса.
Какие записи NS используются для
В основном записи NS определяют имя первичного и вторичного DNS-серверов, отвечающих за зону, и, в более широком смысле, разрешение (доступность) DNS определенного домена.Каждому DNS-серверу из зоны DNS должна быть назначена выделенная NS-запись. На самом деле это функция резервного копирования: это означает, что даже когда первичный DNS отключен, можно отправить запрос разрешения на указанный вторичный DNS-сервер.
Однако роль NS-записей ограничена, поскольку они служат только для определения имени серверов доменных имен внутри зоны, NS-записи не включают IP-адреса, которые обеспечат успешное выполнение запроса разрешения домена. Вот почему администратор назначает IP-адрес в форме записи A записям NS для определенных DNS-серверов (как первичных, так и вторичных).Это означает, что к этим серверам может быть установлено соединение, чтобы разрешение DNS могло быть успешным.
Добавление записи NS | Name.com
Запись NS используется для указания субдомена на набор серверов имен. Их следует использовать только для поддоменов, а не для основного домена. Если вы хотите указать (основной) домен на набор серверов имен, обратитесь к этому руководству.
Записи
NS подходят для использования, когда вы хотите использовать разные серверы имен для поддомена, в результате чего основной домен и поддомен имеют разные наборы серверов имен.
Пример набора NS-записей
Примечание: Если вы хотите настроить запись DNS с помощью Name.com, важно отметить, что вам необходимо использовать наши серверы имен, поэтому name.com управляет вашим DNS и размещает его. Домены, зарегистрированные на Name.com, по умолчанию используют наши серверы имен. Однако, чтобы указать ваш домен на наши серверы имен или убедиться, что они указаны правильно, см. Наше руководство по серверам имен по умолчанию.
После того, как вы воспользуетесь нашими серверами имен, выполните следующие действия:
Войдите под своим именем.com аккаунт.
Нажмите кнопку МОИ ДОМЕНЫ , расположенную в правом верхнем углу.
Щелкните имя домена, для которого хотите создать записи NS.
Щелкните Manage DNS Records.
Здесь вы добавите желаемую запись NS, предоставленную вашим хостом. Вы должны создать как минимум две записи, так как для ее разрешения вам потребуется как минимум два сервера имен.

Первая запись NS:
Выберите NS в раскрывающемся меню Тип .
Введите поддомен в Хост пустое поле
Введите или скопируйте + вставьте сервер имен в поле Ответ .
Оставьте TTL как 300 (по умолчанию)
Нажмите кнопку Добавить запись .

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

Вопросы и ответы по Amazon Route 53 – Amazon Web Services

Руководство по размещению домена и дочернего домена в Azure DNS

В этой статье

Предварительные требования

Создание зоны DNS

Получение серверов имен

Делегирование домена

Проверка делегирования

Очистка ресурсов

Дальнейшие действия

Изменение именных имен для Microsoft 365 с любым регистратором домена — Microsoft 365 admin

В этой статье

Добавьте запись TXT или MX для проверкиAdd a TXT or MX record for verification

Найдите область на веб-сайте поставщика хостинга DNS, в которой можно создать новую записьFind the area on your DNS hosting provider’s website where you can create a new record

Создание записиCreate the record

Сохранение записиSave the record

Изменение записей сервера доменных именChange your domain’s nameserver (NS) records

См. также:Related content

Управление ресурсными DNS-записями домена в Cloudflare

Управлять записями DNS | Домены

Другие действия

Статьи по теме

Помощь: Домены: DNS-записи

Что такое DNS-записи домена?

записей сервера имен (NS) в Avi DNS

Делегированные домены или вырезание зоны

Неделегированные домены

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

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

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

- установка различных записей NS как авторитетных в авторитетном DNS

Что такое записи NS и почему они важны для DNS

NS-Records (авторитетный сервер имен)

NS Record - Хостинг Википедия

Краткий обзор записей NS

Какие записи NS используются для

Добавление записи NS | Name.com

Добавить комментарий Отменить ответ