Разное

Dns cname: DNS записи – NS, CNAME, TXT, A, AAAA

18.08.2018

Содержание

CNAME запись в DNS настройка

CNAME запись в DNS позволяет задавать алиасы — фактически реализуя перенаправление всех запросов одного домена другому домену. Настройка CNAME производится на NS сервере, на который делегирован домен или в панели управления компании, предоставляющей услуги хостинга DNS.

 

 

CNAME — Canonical Name — запись задающая алиас. Рассмотрим принцип работы CNAME

При присутствии CNAME не будут учитываться никакие другие записи DNS.

 

host example.com

 

example.com A 124.124.124.124
example.com A 124.124.124.126
example.com MX 124.124.124.124
example.com CNAME example.ru

 

В приведенном примере записи типов A и MX не будут иметь силы потому, что задан алиас. При запросе к example.com и отсутствии в собственной ьазе необходимого значения DNS будет запрашивать у стоящего выше в иерархии сервера А-запись для example.ru и разрешая ее в IP адрес переадресовывать запрос на него.

Эту особенность CNAME всегда следует иметь в виду и не создавать для того же имени других записей.

 

CNAME часто задается для поддоменов — например:

test.example.com CNAME example.ru

 

 

 

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

 

 

CNAME как и любая другая запись проверяется при помощи запроса к серверу с использованием утилит host и dig

 

host -t cname  _d25ca42cb704f144b5bc80ee3e8be779.example.com

_d25ca42cb704f144b5bc80ee3e8be779.example.com is an alias for 5d9678c35b6f432c4dee7641b066194f.c8d5d2a8d1216b60b9eda8b312ee167a.comodoca.com.

Создание записи псевдонима (CNAME) в DNS для WEB1

  • Чтение занимает 2 мин

В этой статье

Область применения: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Эту процедуру можно использовать для добавления канонического имени псевдонима (записи CNAME) ресурса для веб-сервера в зону в DNS на контроллере домена.You can use this procedure to add an Alias canonical name (CNAME) resource record for your Web server to a zone in DNS on your domain controller. С записями CNAME можно использовать несколько имен для указания на один узел, что упрощает выполнение таких задач, как размещение протокол FTP (FTP) Server и веб-сервера на одном компьютере.With CNAME records, you can use more than one name to point to a single host, making it easy to do such things as host both a File Transfer Protocol (FTP) server and a Web server on the same computer.

По этой причине вы можете использовать веб-сервер для размещения списка отзыва сертификатов () CRL для центра сертификации () ЦС, а также для выполнения дополнительных служб, таких как FTP или веб-сервер.Because of this, you are free to use your Web server to host the certificate revocation list (CRL) for your certification authority (CA) as well as to perform additional services, such as FTP or Web server.

При выполнении этой процедуры замените имя псевдонима и другие переменные значениями, соответствующими развертыванию.When you perform this procedure, replace Alias name and other variables with values that are appropriate for your deployment.

Для выполнения этой процедуры необходимо быть членом группы «Администраторы домена» .To perform this procedure, you must be a member of Domain Admins.

Добавление псевдонима () записи ресурса CNAME в зонуTo add an alias (CNAME) resource record to a zone

  1. На компьютере DC1 в диспетчер сервера щелкните средства , а затем — DNS.On DC1, in Server Manager, click Tools and then click DNS. Откроется консоль управления (MMC) диспетчера DNS.The DNS Manager Microsoft Management Console (MMC) opens.

  2. В дереве консоли дважды щелкните зоны прямого просмотра, щелкните правой кнопкой мыши зону прямого просмотра, в которую нужно добавить запись ресурса псевдонима, и выберите команду создать псевдоним (CNAME) .In the console tree, double-click Forward Lookup Zones, right-click the forward lookup zone where you want to add the Alias resource record, and then click New Alias (CNAME). Откроется диалоговое окно Новая запись ресурса .The New Resource Record dialog box opens.

  3. В поле имя псевдонимавведите имя псевдонима PKI.In Alias name, type the alias name pki.

  4. При вводе значения имени псевдонимаполное

    доменное имя (FQDN) автоматически заполняется в диалоговом окне.When you type a value for Alias name, the Fully qualified domain name (FQDN) auto-fills in the dialog box. Например, если имя псевдонима — PKI, а домен — corp.contoso.com, значение PKI.Corp.contoso.com заполняется автоматически.For example, if your alias name is «pki» and your domain is corp.contoso.com, the value pki.corp.contoso.com is auto-filled for you.

  5. В полном доменном имени (fqdn) для целевого узлавведите полное доменное имя веб-сервера.In Fully qualified domain name (FQDN) for target host, type the FQDN of your Web server. Например, если веб-сервер называется WEB1, а домен — corp.contoso.com, введите Web1.Corp.contoso.com.For example, if your Web server is named WEB1 and your domain is corp.contoso.com, type

    WEB1.corp.contoso.com.

  6. Нажмите кнопку ОК , чтобы добавить новую запись в зону.Click OK to add the new record to the zone.

Различие между DNS-записями А, CNAME, ALIAS и URL

A, CNAME, ALIAS и URL записи существуют для того, чтобы помочь решить задачу с направлением вашего домена (хостнейма) на ваш сайт или сервер. Однако они имеют небольшие отличия в том, как клиент достигнет вашего сайта или сервера.

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

В чем разница

  • А 
    запись направляет hostname или домен на один или несколько IP, когда IP-адрес известен и стабильно работает.
  • CNAME запись направляет имя или домен на другое имя или домен. Использовать стоит только в тех случаях если нет других DNS-записей на этом хостнейме или домене в противном случае остальные записи не будут учитываться и отвечать.
  • ALIAS направляет имя на другое имя, но в то же время данная запись может сосуществовать с другими записями без конфликта.
  • URL перенаправляет запрос к имени на другое имя используя 301 HTTP-редирект.

Правила, которые стоит запомнить:

  • Записи A, CNAME и АЛИАС резолвятся и отдают по доменному имени IP-адрес. В тоже время URL запись наоборот переадресовывает запрос по доменному имени к пункту назначения, а именно на другое имя или другой URL. URL запись это эффективный и простой способ перенаправить одно имя на другое, к примеру, www.novall.net на novall.net .
  • А запись должна быть направлена на IP-адрес, а CNAME и ALIAS должны быть направлены на другой домен или хост.

Какие записи и в каких ситуациях лучше использовать

  • Используйте А запись, в случаях когда вы точно знаете, что определённый IP закреплён за определённой машиной или сервером.
  • Используйте CNAME запись в тех случаях когда вам нужно направить доменное имя на другое доменное имя и у вас нет необходимости в других DNS-записях (таких как MX записи для работы почты и т.д.) для этого домена.
  • Используйте ALIAS когда вам нужно направить одно доменное имя на другое но при этом вы планируете использовать и другие DNS-записи.
  • Используйте URL запись когда вам нужно выполнить редирект (переадресацию или сменить адрес) с одного доменного имени на другое.

И ЗАПОМНИТЕ ВАМ НИКОГДА НЕ СТОИТ ИСПОЛЬЗОВАТЬ CNAME ЗАПИСЬ НА ГЛАВНОМ ДОМЕНЕ (например для такого главного домена как novall.net).

(Просмотрено 9 803 раз, 11 просмотров сегодня)

Что такое DNS – Hexlet Guides

Содержание
  1. Предпосылки появления DNS
  2. Файл hosts — как первый шаг к созданию DNS
  3. Работа DNS в сети интернет
    1. Терминология
    2. Подключение
    3. Рекурсия в DNS
  4. Ресурсные записи DNS
  5. Пример реальных записей DNS
  6. Выводы

DNS ≠ магазин компьютерной и бытовой техники

Domain Name System — распределённая система хранения и обработки информации о доменных именах доменных зонах.

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

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

Предпосылки появления DNS

В 70-х годах, когда ARPANET (прародитель интернета) был небольшим и состоял из нескольких сотен компьютеров, создатели этой сети задались идеей «очеловечить» адреса компьютеров внутри сети для удобного обращения и передачи информации между ними. До того момента обращения происходили посредством указания точного адреса необходимого компьютера внутри этой сети (IP-адрес), что было неудобно, даже при таком небольшом количестве устройств.

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

С увеличением количества компьютеров внутри сети ARPANET людям приходилось запоминать всё большее количество разнообразных комбинаций цифр (IP-адресов), чтобы связаться с тем или иным компьютером для отправки данных. Это могли быть данные об исследованиях, необходимые отделу компании, который находится в другой части страны, или любые другие данные, расположенные на расстоянии. К 1983 году таких компьютеров насчитывалось более 4 000, и запомнить большинство этих адресов уже не представлялось возможным. Вот и разработчики ARPANET подумали также, решив дать компьютерам уникальные имена для дальнейшего подключения к ним с использованием этих имён, а не IP-адресов.

Файл hosts — как первый шаг к созданию DNS

Для решения этой задачи разработчики решили использовать словарь, который связывал уникальное имя и IP-адрес каждого компьютера в сети. Таким словарём стал файл hosts.txt, который и отвечал за привязку IP-адреса к имени компьютера. Файл лежал на сервере Стэнфордского исследовательского института, и пользователи сети регулярно вручную скачивали этот файл на свои компьютеры, чтобы сохранять актуальность словаря, ведь новые компьютеры появлялись в сети почти каждый день.

Выглядел hosts.txt тогда (да и сейчас) таким образом:

192.168.10.36         MIKE-STRATE-PC
Сетевой (IP) адрес    Имя компьютера

При наличии такого файла на компьютере пользователя для связи с компьютером Майка, можно было не запоминать цифры, а использовать понятное латинское имя «MIKE-STRATE-PC».

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

  • В Unix-системах: /etc/hosts
  • В Windows-системах: %Путь до папки Windows%/system32/drivers/etc/hosts

Компьютеру с IP-адресом 192.168.10.36, который находится внутри локальной сети мы указали имя «MIKE-STRATE-PC». После чего можно воспользоваться командой ping, которая пошлёт специальный запрос на компьютер Майка и будет ждать от него ответа. Похоже на то, как вы стучитесь в дверь или звоните в звонок, чтобы узнать, «есть ли кто дома?» Такой запрос можно послать на любой компьютер.

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

В 1984 году Пол Мокапетрис (Paul Mockapetris) описал новую систему под названием DNS (Domain Name System / Система доменных имён), которая была призвана автоматизировать процессы соотнесения IP-адресов и имён компьютеров, а также процессы обновления имён у пользователей без необходимости ручного скачивания файла со стороннего сервера.

Работа DNS в сети интернет

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

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

dns, hierarchy

Рассмотрим работу DNS и её составных частей поближе.

Терминология

О

Как управлять DNS-записями домена?

Если вы успешно прикрепили свой домен к сайту в uKit, то вам становится доступно редактирование DNS-записей в настройках домена. Чтобы попасть в редактирование записей, перейдите в раздел «Домены», откройте вкладку «Прикреплённые домены» и напротив нужного вам домена нажмите на шестерёнку. Перед вами откроется окно с несколькими вкладками, перейдите во вкладку «Редактирование записей» — именно здесь вам будет доступно добавление различных DNS-записей в настройках домена.

Для размещения доступны несколько видов записей:

Каждая из этих записей используются для различных целей, рассмотрим каждую запись отдельно.

MX-записи

MX-запись предназначена для работы электронной почты. По умолчанию записи размещаются следующим образом:

  • Name: @ (если вы подключаете почту для текущего домена)
  • Preference: 10
  • Exchange: Адрес сервера

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

  • @ MX 10 mx.yandex.net
  • @ MX 10 emx.mail.ru

TXT-записи

TXT-запись содержит в себе какую-либо текстовую запись. Широко применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также для записи SPF и ключа DKIM. По умолчанию записи размещаются следующим образом:

  • Name: @ (либо имя поддомена)
  • TXT-DATA: Любая текстовая информация

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

  • @ TXT v=spf1 redirect=_spf.yandex.net
  • mail._domainkey TXT v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCm+3/BtqNb0jb0O3R2t/T3qJedMUQM78Me6wFVuMfuNUWpTIbFkst7QiaF7K4YezusS/UmZjbt5fRgZArbWxMMuy2/Rn/iQEvhDN+BLAbGi0tr3U+rp3lAOKly/cc2Kum2/Y+IE08SKuUq3aHQlkZnMcDY7KYmuHB98Kl8uI/gYQIDAQAB

CNAME-записи

CNAME-запись позволяет присваивать желаемому адресу псевдоним. Этот псевдоним обычно связывает с адресом какую-нибудь функцию (например, чтобы можно было попасть в почту для домена введя mail.mysite.ru), либо просто сокращает его имя. CNAME-запись по умолчанию заполняется следующим образом:

  • Name: Имя поддомена
  • CNAME: Адрес, на который будет ссылаться указанный поддомен

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

  • mail CNAME domain.mail.yandex.net
  • mail CNAME biz.mail.ru

A-записи

A-запись позволяет указать для домена IP-адрес сервера, на котором размещён сайт для этого адреса. Подобные записи используются для направления доменов и поддоменов на другие сервера. По умолчанию записи размещаются следующим образом:

  • Name: Имя поддомена
  • Address: IP-адрес сервера

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

Примечание:

А-запись для основного домена по умолчанию уже установлена и изменить её не получится.

SRV-записи

SRV-запись — стандарт в DNS, определяющий местоположение, то есть имя хоста и номер порта серверов для определённых служб. Большинство сервисов предоставляют SRV-запись в следующем виде:

  • _service._proto.name TTL class SRV priority weight port target

В конструкторе uKit они по умолчанию размещаются следующим образом:

  • Name: Название сервиса и протокола
  • Priority: Приоритет
  • Weight: Вес
  • Port: Порт
  • Target: Цель

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

  • _xmpp-server._tcp SRV 20 0 5269 domain-xmpp.ya.ru
  • _autodiscover._tcp SRV 0 0 443 autodiscover.secureserver.net

Совет:

Если вам необходимо указать другие записи, напишите в службу поддержки.

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

Статья оказалась полезной для 113 человек

Как проверить DNS-записи домена 📝

13 марта 2020

842

Время чтения ≈ 10 минут

Проверка DNS записей домена - лучшие бесплатные сервисы

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

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

Типы DNS-записей

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

Проверка DNS-записей домена - типы записей

Наиболее важные типы DNS-записей приведены в списке ниже.

  • A-запись — находит IP-адрес сервера по введенному названию сайта в адресную строку браузера.
  • CNAME-запись — указывает на несколько поддоменов на одном сервере.
  • MX-запись — указывает сервер, который отвечает за прием почты для данного домена.
  • TXT-запись — информационная запись с информацией для внешних источников (хранит до 255 байт). Часто используется для подтверждения прав собственности на домен.

Подробно о работе DNS и типах записей можно прочитать в нашей базе знаний.

Зачем проверять DNS-записи

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

Проверка DNS записей домена - лучшие бесплатные сервисы 1

Windows и Linux утилиты для проверки DNS-записей

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

  • NSLookUp (Linux, Windows). Встроенная утилита позволяет узнать точные данные об IP-адресе домена (включая скорость получения), а также о настройке всех DNS-записей для него. В Windows запускается командой nslookup -type=<тип записи> example.com в командной строке (где вместо «example.com» нужно подставить нужный сайт). В Linux это делается аналогичным образом.
  • Dig — «Domain information groper» (Linux, Windows). Аналог NSLookUp, входящий в базовую комплектацию программного обеспечения к DNS-серверу BIND.
  • DNSBasic (Windows). Утилита диагностики домена, которая, помимо прочих функций, опрашивает DNS-записи сервера.
  • Host (Linux). Стандартная утилита в командной строке для проведения всех видов запросов к DNS-серверу.

Лучшие бесплатные сервисы для проверки DNS-записей

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

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

Pr-Cy

Проверка DNS-записей домена - pr-cy.ru

Многофункциональный портал для владельцев и администраторов сайта, SEO-специалистов и копирайтеров. Простой в использовании сервис поможет выполнить полную проверку сайта, даже новичку. Большая часть функций доступна бесплатно. Сервис умеет проверять следующие типы DNS-записей: TXT, MX, A, SOA, NS.

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

Кроме этого, сервис посчитает стоимость сайта, поможет создать превью и favicon, покажет все сайты с одного IP-адреса, определит CMS, выполнит полный SEO-анализ сайта с учетом указания ключевых слов и их позиций в поисковых системах и многое другое.

Особенности

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

2whois

Проверка DNS-записей домена - 2whois.ru

Удобный и бесплатный сервис для системных администраторов и веб-мастеров, разработчики которого решили сфокусироваться на технической стороне проверки. Сервис умеет проверять следующие типы DNS-записей: TXT, MX, A, SOA, NS, PTR.

Основные возможности
  • Проверка DNS-записей.
  • Вывод WHOIS-информации о домене.
  • Встроенная поддержка распространенных утилит (NSLookUp, Dig, PTR).
  • Возможность проверки пинга (ping) сайта.
  • Вывод полного маршрута пакетов до конечного сервера через Traceroute.
  • Контроль работоспособности сайта из различных точек земного шара.

Дополнительно, поможет проверить сайт на вирусы и его наличие в базах Роскомнадзора и в спам-базах.

Особенности

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

2ip

Проверка DNS-записей домена - 2ip

Еще один многофункциональный сервис. Может проверить TXT-запись, а также следующие типы записей: ANY, A, NS, CNAME, MX, PTR, SOA, LOC, RP, AXFR, SRV.

Основные возможности
  • Проверка DNS и IP.
  • Предоставление VPN-сервера.
  • Вывод информации о браузере посетителя.
  • Измерение скорости работы сайта.
  • Проверка доставки E-mail и защиты от спама.
  • Проверка E-mail на взлом через наличие логинов и паролей в соответствующих базах данных (которые были украдены и уже использовались в недобросовестных целях).
Особенности

2IP.RU выступает помощником веб-мастерам и администраторам интернет-ресурсов. Введя домен в соответствующее поле, можно получить сконфигурированные записи. Их останется скопировать и вставить в панели управления хостингом.

MXToolbox

Проверка DNS-записей домена - DNSLookup

Зарубежный сервис является оболочкой для утилиты NSLookup. В отличие от утилиты, встроенной в операционные системы, сервис не требует специальных знаний и сразу выводит записи типа: A.

Основные возможности
  • Проверка DNS-записей.
  • Проверка домена в черных списках.
  • Диагностика SMTP-сервера.
  • Полная проверка «здоровья сайта» по домену (антивирусная проверка, DNS, E-mail).
  • Проверяет заголовки сервера.
  • Автоматический условно-бесплатный мониторинг сайта (бесплатный тариф рассчитан на 7 дней и 30 проверок с поиском по одному черному списку),
  • Проверка HTTP и HTTPS запросов.
Особенности

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

NetTOOLS

 

NetTOOLS

Функциональность online-сервиса обеспечена встроенными в него утилитами. Они помогают быстро и легко проверить разные параметры работоспособности сайта. Сервис проверяет записи следующих типов: ANY, SOA, A, MX, NS, PTR, TXT, CNAME, SRV, LOC.

Основные возможности
  • Полная проверка DNS по зонам и записям.
  • Обеспечение полной функциональности утилит NSLookUp, Ping, Traceroute, WHOIS.
  • Выполнение тестов на проверку работоспособности хоста (мониторинг доступности, измерение скорости работы хоста, тестирование NTP и Proxy серверов).
  • Анализ почтовых серверов на предмет правильной настройки, включая попадание домена в спам-листы.
  • Вывод информации о HTTP заголовках, SSL-сертификатах и метатегах.
  • FTP-подключение через браузер к ресурсу для просмотра контента. Это удобно, когда под рукой нет специальных утилит, а проверку сделать надо.
Особенности

Этот ресурс оснащен библиотекой и расширенной документацией. Такой подход помогает выполнить необходимые проверки, сравнить результаты с библиотекой сервиса, скорректировать настройки для изменения.

functions-online

Проверка DNS-записей домена - functions-online

Моделирует работу PHP-функций онлайн. Является удобным помощником при отладке кода, написанного на языке PHP. В PHP есть функция получения DNS-записей домена. Через него можно проверить наличие определенных DNS-записей: ANY, ALL, A, CNAME, HINFO, MX, NS, PTR, SOA, TXT, AAAA, SRV, NAPTR, A6.

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

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

Вывод

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

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

Чтобы сайт был не только доступен в интернете, но и работал бесперебойно, нужно обеспечить его достойной платформой. VPS от Eternalhost — хостинг на быстрых NVMe-дисках с круглосуточной техподдержкой и защитой от DDoS-атак.

Оцените материал:

[Всего голосов: 1    Средний: 5/5]

DNS сервер BIND (теория) / Хабр

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

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


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

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

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

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

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

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

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

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

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

Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др). Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия — именами хостов, которые задаются соответствующими ресурсными записями или хостовыми записями.

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

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

  • имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
  • Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
  • класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
  • тип (TYPE) — тип записи синтаксис и назначение записи
  • данные (DATA) — различная информация, формат и синтаксис которой определяется типом.

При этом, возможно использовать следующие символы:
  • ;   —  Вводит комментарий
  • #  —  Также вводит комментарии (только в версии BIND 4.9)
  • @  — Имя текущего домена
  • ( )    — Позволяют данным занимать несколько строк
  • *    — Метасимвол (только в поле имя)

Со всем набором ресурсных записей можно ознакомиться в wikipedia. Наиболее часто применяемые ресурсные записи следующими (далее, мы обязательно рассмотрим их на практике):
  • A — (address record/запись адреса) отображают имя хоста (доменное имя) на адрес IPv4. Для каждого сетевого интерфейса машины должна быть сделана одна A-запись. Например, следующая запись отображает доменное имя k-max.name. в IPv4 адрес хоста 81.177.139.65 (поле NAME k-max.name., поле TTL 86400, поле CLASS IN, поле DATA 81.177.139.65):
    k-max.name.             86400   IN      A       81.177.139.65
  • AAAA (IPv6 address record) аналогична записи A, но для IPv6.
  • CNAME (canonical name record/каноническая запись имени (псевдоним)) — отображает алиас на реальное имя (для перенаправления на другое имя), например, следующая запись задает алиас ftp для хоста www.k-max.name.:
    ftp             86400   IN      CNAME       www.k-max.name.
  • MX (mail exchange) — указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритет и через пробел — доменное имя хоста, ответственного за прием почты. Например, следующая запись показывает, что для домена k-max.name направлять почту сначала на mx.k-max.name, затем на mx2.k-max.name, если с mx.k-max.name возникли какие-то проблемы. При этом, для обоих MX хостов должны быть соответствующие A-записи:
    k-max.name.             17790   IN      MX      10 mx.k-max.name.
    k-max.name.             17790   IN      MX      20 mx2.k-max.name.
  • NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:
    name.                   5772    IN      NS      l6.nstld.com.
    name.                   5772    IN      NS      m6.nstld.com.
    name.                   5772    IN      NS      c6.nstld.com.
    name.                   5772    IN      NS      j6.nstld.com.
    ......

    зону k-max.name обслуживают:
    k-max.name.             1577    IN      NS      ns2.jino.ru.
    k-max.name.             1577    IN      NS      ns1.jino.ru.
  • PTR (pointer) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).
  • SOA (Start of Authority/начальная запись зоны) — описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. Поле Name содержит имя домена/зоны, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами: имя главного DNS (Primary Name Server), адрес администратора зоны, далее в скобках — серийный номер файла зоны (Serial number). При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — значения таймеров (Refresh — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry — время ожидания после неудачной попытки опроса, Expire — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL — минимальное время, в течение которого данные остаются в кэше вторичного сервера). Ниже в примере приведено 2 одинаковые записи SOA (хотя вторая и записана в несколько строк), но они одинаковы по значению и формат записи второй более понятен в силу его структурированности:
    k-max.name.             86400   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400
    k-max.name.             86400   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. (
                                                      2011032003 ; serial (серийный номер)
                                                      28800 ; refresh (обновление)
                                                      7200 ; retry (повторная попытка)
                                                      604800 ; expire (срок годности)
                                                      86400) ; minimum TTL (минимум)
  • SRV (server selection) — указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например  Jabber и Active Directory).

Давайте рассмотрим, что есть Делегирование. Делегирование (корректнее сказать делегирование ответственности) — это операция передачи ответственности за часть дерева доменных имен (зону) другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон. Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При этом, в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны. Например, на иллюстрации корневой домен делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 5 уровней.

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

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

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

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

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
[email protected]:~# cat /etc/nsswitch.conf
......
hosts:          files dns
networks:       files

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:
[email protected]:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain  examle.com

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP  и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

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

Давайте разберем, что тут нарисовано по шагам:

  1. Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
  2. Резолвер посылает запрос указанному серверу имен.
  3. Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
  4. Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
  5. Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
  6. пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
  7. и «вложенности» доменных имен.
  8. В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
  9. Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

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

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

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

Ответы DNS сервера

Ответы DNS бывают следующего типа:
  • Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
  • Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Ответ DNS обычно содержит следующую информацию:
  • Запись заголовка — служебную информацию о запросе.
  • Запись запроса — повторяет отправленный запрос.
  • Запись ответа — собственно, сам ответ.
  • Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
  • Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

Вышенаписанное наглядно подтверждается утилитой dig:
[email protected]:~# dig ya.ru
; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION: (раздел запроса)
;ya.ru.                         IN      A

;; ANSWER SECTION: (раздел ответа)
ya.ru.                  4813    IN      A       87.250.250.203
ya.ru.                  4813    IN      A       87.250.251.3
ya.ru.                  4813    IN      A       93.158.134.3
ya.ru.                  4813    IN      A       93.158.134.203
ya.ru.                  4813    IN      A       213.180.204.3
ya.ru.                  4813    IN      A       77.88.21.3
ya.ru.                  4813    IN      A       87.250.250.3

;; AUTHORITY SECTION: (авторитативные сервера)
ya.ru.                  4813    IN      NS      ns1.yandex.ru.
ya.ru.                  4813    IN      NS      ns5.yandex.ru.

;; ADDITIONAL SECTION: (дополнительная информация - адреса авторитативных name servers)
ns5.yandex.ru.          345565  IN      A       213.180.204.1
ns1.yandex.ru.          345565  IN      A       213.180.193.1
ns1.yandex.ru.          3565    IN      AAAA    2a02:6b8::1

;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Jul  2 23:02:45 2011
;; MSG SIZE  rcvd: 238

Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле TypePTR, а в поле DataFQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Наглядно приведенную схему можно представить командами:

[[email protected]~]# dig www.ru
...
;; QUESTION SECTION:
;www.ru                                IN      A

;; ANSWER SECTION:
www.ru                 52119   IN      A       194.87.0.50
...
[[email protected]~]# dig -x 194.87.0.50
...
;; QUESTION SECTION:
;50.0.87.194.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
50.0.87.194.in-addr.arpa. 30385 IN      PTR     www.ru
....

При этом, команду dig -x 194.87.0.50 правильнее будет представить как dig 50.0.87.194.in-addr.arpa., то есть записи в поддоменах *.in-addr.arpa. представлены в так называемой обратной нотации (или reverse форме), то есть хосту с IP 194.87.0.50 будет соответствовать PTR-запись, имеющая FQDN 50.0.87.194.in-addr.arpa., которая в свою очередь указывает на домен www.ru  Хочется отметить, что чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.

Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины www.ru. будет иметь такой вид:

50.0.87.194 IN PTR www.ru

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно «www.ru». Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

80 IN PTR www.ru
Регистрация доменных имен

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

Регистрация доменов — это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.

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

Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:

  • корневой домен
  • все домены первого уровня (TLD)
  • некоторые домены второго уровня (например, com.ru или co.uk)

Регистратором для корневого домена является организация ICANN. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs …), необходимо получить аккредитацию ICANN.

Правила регистрации в международных (gTLD — com., org, и др.) доменах устанавливаются ICANN. Правила регистрации в национальных (ccTLD — ru, us и др.) доменах устанавливаются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и.рф задаются Координационным центром национального домена сети Интернет. Для многих доменов (в том числе и для ru) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.

Услуга регистрации домена в большинстве случаев платная, цену и условия регистрации определяет регистратор. Для регистрации домена, необходимо выбрать свободное имя и отправить заявку на регистрацию у одного из регистраторов (например nic.ru), оплатить предоставление услуги. После подтверждения регистрации, необходимо в интерфейсе регистратора определить (делегировать) dns сервера, скорее всего это будут DNS вашего хостера.

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

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

man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname:  http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: скачать.
RFC882, 1035, 1183

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

Настройка записи DNS CNAME (Canonical Name) для ваших доменных имен

Запуск доменного имени — это многосторонний процесс благодаря множеству возможностей управления DNS, предлагаемых провайдерами веб-хостинга. Большинство хостов сегодня предлагают несколько вариантов управления настройками DNS вашего домена, среди которых — записи CNAME.

CNAME Records

Запись CNAME — это аббревиатура от Canonical Name Records, которая отвечает за псевдонимы реального имени хоста компьютера, все это разрешено DNS.Это необходимо, когда DNS-сервер разрешает несколько доменных имен в один и тот же IP-адрес. Важно знать, что компьютер может иметь неограниченное количество псевдонимов CNAME, но вы должны установить отдельную запись CNAME в базе данных для каждого из них.

Примеры:

; фрагмент зоны для example.com
$ TTL 2d ; зона по умолчанию = 2 дня или 172800 секунд
$ ORIGIN example.com.
….
сервер1 В А 192.168.0.5
www IN CNAME server1
ftp IN CNAME server1

; фрагмент файла зоны для example.com
joe IN A 192.168.254.5
www IN CNAME joe ; каноническое имя joe.example.com.
www IN CNAME joe.example.com.
; точно так же, как выше
ftp IN CNAME www.example.com. ; не очень хорошая практика
; лучшая практика для достижения того же
; результат как ftp CNAME выше
; путем повторного определения того же физического хоста с 2 А записями
футов в А 192.168,254,5
; следующая строка перенаправляет marta.example.com на
; maria.another.com
marta IN CNAME maria.another.com.

Используя наш расширенный инструмент Custom DNS Manager, клиенты NTC-хостинга могут добавлять, редактировать или удалять записи CNAME несколькими щелчками мыши. Чтобы добавить запись CNAME, вам нужно всего лишь войти в панель управления веб-хостинга, перейти в раздел «Пользовательские записи DNS» и выбрать CNAME из раскрывающегося списка «Тип».

Затем необходимо добавить URL-адрес, на который должен указывать ваш домен, и настроить параметры TTL (по умолчанию они равны 3600 секундам).

Вам может потребоваться установить записи CNAME для вашего домена (-ов) в различных случаях — если вам нужно указать субдомен на внешний сервер (отличный от хоста), не используя IP-адрес этого сервера напрямую; когда вы хотите создать общие имена или когда вы переименовываете хост и вам больше не нужно его текущее имя.

В разделе «Пользовательские записи DNS» панели управления веб-хостинга с NTC-хостингом вы можете установить собственные записи CNAME для своих доменных имен.Просто выберите имя домена из раскрывающегося списка и введите соответствующее значение записи CNAME.

Примечание: Запись CNAME всегда должна указывать на IP-адрес или имя хоста. Если запись CNAME указывает на другую запись CNAME, это может вызвать зацикливание DNS. Другие записи DNS также не должны указывать на запись CNAME.

DNAME запись

Запись DNAME очень похожа на запись CNAME, но, хотя запись CNAME применяется только для одного имени, с помощью записи DNAME можно создать псевдоним для всех записей домена или sudbomain.Тем не менее, использование записей DNAME вызывает много работы для распознавателей, поэтому его использование должно быть ограничено и только на короткий период времени.

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

research.example.com IN DNAME r-and-d.example.com
военных.r-и-d.example.comi В 192,168,0,5
топлива.r-and-d.example.com В 192.168.0.4

Таким образом, все записи для r-and-d.example.com будут также присутствовать для research.example.com, а fuel.r-and-d.example.com будет возвращать тот же результат, что и fuel.research.example. ком.

,

Что такое запись CNAME? — DNSimple Help

Оглавление


Что такое запись CNAME?

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

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

  • Запись A для примера .com , указывающий на IP-адрес сервера
  • A CNAME запись для www.example.com , указывающая на example.com

В результате example.com указывает на IP-адрес сервера, а www.example.com указывает на тот же адрес через example.com . Если IP-адрес изменится, вам нужно будет обновить его только в одном месте: просто отредактируйте запись A для example.com , и www.example.com автоматически наследует изменения.

Запись CNAME всегда должна указывать на другое доменное имя, а не на IP-адрес.

DNS-запись A указывается в RFC 1035.

Ограничения

  1. Запись CNAME всегда должна указывать на другое доменное имя, а не на IP-адрес.
  2. Запись CNAME не может сосуществовать с другой записью с таким же именем. Невозможно иметь записи CNAME и TXT для www.example.com .
  3. CNAME может указывать на другое CNAME, хотя эта конфигурация обычно не рекомендуется из соображений производительности.Когда это применимо, CNAME должен указывать как можно ближе к целевому имени, чтобы избежать ненужных потерь производительности.

CNAME формат записи

Структура записи A соответствует стандартному определению формата верхнего уровня, определенному в RFC 1035. Раздел RDATA состоит из одного элемента:

доменное имя Доменное имя, которое указывает каноническое или основное имя записи.

Каноническое представление:

  CNAME <имя домена>
  

, где <имя-домена> — полное доменное имя, например, example.com .

В DNSimple запись CNAME представлена ​​следующими настраиваемыми элементами:

Имя Имя хоста для записи, без имени домена. Обычно это называется «поддомен».Мы автоматически добавляем доменное имя.
TTL Время жизни в секундах. Это количество времени, в течение которого запись может быть кэширована распознавателем.
Содержимое Доменное имя, на которое отображается CNAME.

CNAME и Redirect

Запись CNAME иногда неправильно называется перенаправлением , как правило, в контексте веб-перенаправлений (HTTP).

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

Вы можете узнать больше, прочитав различия между записями A, CNAME, ALIAS и URL. DNSimple предоставляет специальную запись URL, которую можно использовать для настройки перенаправления HTTP.

Запрос записей CNAME

Вы можете использовать dig для определения записи CNAME, связанной с доменным именем. Результат содержится в разделе ОТВЕТ . Он содержит полное доменное имя (FQDN), оставшееся время жизни (TTL) и имя домена.

  $ копай CNAME www.dnsimple.com

; << >> DiG 9.10.6 << >> CNAME www.dnsimple.com
;; глобальные параметры: + cmd
;; Получил ответ:
;; - >> HEADER << - код операции: QUERY, статус: NOERROR, id: 5274
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 0, ДОПОЛНИТЕЛЬНО: 1

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флаги :; Удп: 512
;; РАЗДЕЛ ВОПРОСА:
; WWW.dnsimple.com. В CNAME

;; ОТВЕТ РАЗДЕЛ:
www.dnsimple.com. 3599 В CNAME dnsimple.com.

;; Время запроса: 52 мсек
;; СЕРВЕР: 8.8.8.8 # 53 (8.8.8.8)
;; КОГДА: Пт 02 ноября 20:33:09 CET 2018
;; MSG РАЗМЕР rcvd: 59
  

Управление записями CNAME

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

,

CNAME Lookup - Проверьте DNS CNAME запись домена

DNS-сервер Рекурсивный сервер имен Укажите имя сервера Авторитетный сервер имен Сервер доменных имен верхнего уровня Корневой сервер имен

DNS-сервер IP или имя хоста 8.8.8.8 - Google Public DNS 8.8.4.4 - Google Public DNS 2001: 4860: 4860 :: 8888 - публичный DNS Google 2001: 4860: 4860 :: 8844 - публичный DNS Google 1.1.1.1 - Cloudflare 1.0.0.1 - Cloudflare 2606: 4700: 4700 :: 1111 - Облачный свет 2606: 4700: 4700 :: 1001 - Облачный свет 9.9.9.9 - Quad9 149.112.112.112 - Quad9 2620: fe :: fe - Quad9 2620: fe :: 9 - Quad9 208.67.222.222 - OpenDNS 208.67.220.220 - OpenDNS 2620: 119: 35 :: 35 - OpenDNS 2620: 119: 53 :: 53 - OpenDNS 209.244.0.3 - Уровень 3 209.244.0.4 - Уровень 3 4.2.2.1 - Уровень 3 4.2.2.2 - Уровень 3 4.2.2.3 - Уровень 3 4.2.2.4 - Уровень 3 4.2.2.5 - Уровень 3 4.2.2.6 - Уровень 3 64.6.64.6 - Verisign 64.6.65.6 - Verisign 2620: 74: 1b :: 1: 1 - Verisign 2620: 74: 1с :: 2: 2 - Verisign 74.82.42.42 - Ураган Электрик 2001: 470: 20 :: 2 - Ураган Электрик 8.26.56.26 - Comodo Secure DNS 8.20.247.20 - Comodo Secure DNS 199.85.126.10 - Norton ConnectSafe 199.85.127.10 - Norton ConnectSafe 195.46.39.39 - SafeDNS 195.46.39.40 - SafeDNS 84.200.69.80 - DNS.WATCH 84.200.70.40 - DNS.WATCH 185.121.177.177 - OpenNIC 169.239.202.202 - OpenNIC 2a05: dfc7: 5 :: 53 - OpenNIC 2a05: dfc7: 5 :: 5353 - OpenNIC 37.235.1.174 - FreeDNS 37.235.1.177 - FreeDNS 80.80.80.80 - Freenom World 80.80.81.81 - Freenom World 216.131.65.63 - StrongDNS 216.131.65.60 - StrongDNS 176.103.130.130 - AdGuard 176.103.130.131 - AdGuard 2a00: 5a60 :: ad1: 0ff - AdGuard 2a00: 5a60 :: ad2: 0ff - AdGuard 91.239.100.100 - UncensoredDNS 2001: 67c: 28a4 :: - UncensoredDNS 89.233.43.71 - без цензуры 2a01: 3a0: 53: 53 :: - UnnsensoredDNS 77.88.8.8 - Яндекс.DNS 77.88.8.1 - Яндекс.DNS 2a02: 6b8 :: лента: 0ff - Яндекс.DNS 2a02: 6b8: 0: 1 :: подача: 0ff - Яндекс.DNS 216,146,35,35 - Дин 216,146,36,36 - Дин 129.250.35.250 - NTT 129.250.35.251 - NTT 2001: 418: 3ff :: 53 - NTT 2001: 418: 3ff :: 1: 53 - NTT 1.2.4.8 - SDNS 210.2.4.8 - SDNS 240C :: 6666 - CFIEC 240C :: 6644 - CFIEC 223.5.5.5 - AliDNS 223.6.6.6 - AliDNS 2400: 3200 :: 1 - AliDNS 2400: 3200: баба :: 1 - AliDNS 119.29.29.29 - DNSPod 119.28.28.28 - DNSPod 182.254.116.116 - DNSPod 182.254.118.118 - DNSPod 180,76,76,76 - BaiduDNS 2400: da00 :: 6666 - BaiduDNS 114.114.114.114 - 114DNS 114.114.115.115 - 114DNS 168.95.1.1 - HiNet 168.95.192.1 - HiNet 2001: b000: 168 :: 1 - HiNet 2001: b000: 168 :: 2 - HiNet 101.101.101.101 - Quad101 101.102.103.104 - Quad101 2001: de4 :: 101 - Quad101 2001: de4 :: 102 - Quad101

DNS запись

Доменное имя или имя хоста

Расширенный режим

DNSSEC

CNAME Lookup - Проверьте DNS CNAME запись домена

,

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *