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

DNS-записи домена — введение

Доменные имена

Общая группа доменов указывается справа. В приведенных ниже примерах домен верхнего уровня или TLD — это .com.

example.com
mail.hello.example.com

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

Серверы имен

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

Серверы имен размещают информацию о домене DNS в текстовом файле, который называется файлом зоны. Они также известны как записи Start of Authority (SOA). Вы можете разместить свою информацию DNS на серверах имен в одном из нескольких мест:

• Регистратор домена;
• Ваш собственный DNS-сервер;
• Сторонний DNS-хостинг.

DNS-записи и файлы зон

Записи DNS сопоставляют доменные имена с IP-адресами. Затем DNS-записи автоматически объединяются в файл зоны, что позволяет подключенным устройствам искать правильный IP-адрес домена. Если вы решите использовать серверы имен Linode, диспетчер DNS поможет создать файл зоны. Он содержит следующие записи:

; example.com 
$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-записи. Вы можете создавать множество записей для любого количества поддоменов.

Разрешение DNS

Доменное имя должно быть переведено на IP-адрес. DNS сопоставляет понятные пользователю доменные имена (example.com) с IP-адресами (192.0.2.8). Это происходит в специальном текстовом файле, называемом файлом зоны. В нем перечислены домены и соответствующие им IP-адреса. Файл зоны похож на телефонную книгу, в которой имена совпадают с адресами улиц.

Вот как работает процесс поиска DNS:

1. Вы вводите доменное имя, например com,в адресную строку браузера.
2. Компьютер подключен к интернету через провайдера (ISP). DNS-преобразователь интернет-провайдера запрашивает у корневого сервера имен соответствующий сервер имен TLD.
3. Корневой DNS-сервер отвечает IP-адресом для сервера имен .com.
4. DNS-распознаватель провайдера использует IP-адрес, полученный от корневого сервера имен.
5. Сервер имен .comотвечает IP-адресом сервера имен com.
6. DNS-распознаватель ISP считывает файл зоны с сервера имен домена.
7. Файл зоны показывает, какой IP-адрес соответствует домену.
8. Теперь, когда у провайдера есть IP-адрес для com, он возвращает его браузеру, который затем обращается к серверу сайта.

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

Но кэширование может стать проблемой, если вы недавно внесли изменения в информацию о DNS. Для ее решения измените значение времени жизни файла зоны (TTL), чтобы обновление DNS происходило быстрее.

Рекурсия

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае имеет место рекурсия: сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является авторитетным для зоны org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является авторитетным для зоны wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

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

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

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

Второй способ

Вы можете воспользоваться бесплатной поддержкой DNS, входящей в стандартный пакет услуг «Reg.Dedicated». Для этого вам предоставляется удобный интерфейс для управления зоной на базе ISPmanager и DNSmanager. При пользовании данной услугой у вашего регистратора для домена в качестве DNS-серверов необходимо прописывать: и .

Если вместе с услугой «Аренда сервера» вы заказали панель управления ISPmanager

1. 1.
   Зайдите в вашу панель управления ISPmanager с правами администратора.
2. 2.
   Перейдите в раздел Доменные имена.
3. 3.
   Нажмите на Вторичные серверы имен.
4. 4.
   Нажмите Зарегистрировать новый внешний сервер имен.
5. 5.
   В поле «URL панели управления» введите .
6. 6.
   В поле «Пользователь» введите ваш логин вида .
7. 7.
   В поле «Пароль» введите ваш пароль для доступа к DNS (не следует путать его с паролем пользователя root).
8. 8.
   Нажмите ОК.
9. 9.
   Повторите операцию добавления вторичного сервера имён для адреса .
10. 10.
    Нажмите на Настройки доменов по умолчанию.
11. 11.
    В поле «Серверы имён» введите и .
12. 12.
    Поставьте галочку «Изменить для всех доменов».
13. 13.
    Нажмите ОК.

Теперь при создании домена в панели управления вашим сервером домен будет автоматически создан на вторичных серверах ns5.hosting.reg.ru и ns6.hosting.reg.ru, которые вы сможете прописать как DNS-сервера для данного домена у вашего регистратора.

Выделенный сервер в качестве первичного DNS-сервера

Если вы не заказывали панель управления ISPmanager и хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления вторичными серверами имён:

1. 1.
   Зайдите в панель управления DNSmanager (https://ns5.hosting.reg.ru/manager/dnsmgr), используя логин вида d0000000 и пароль для доступа к DNS (не следует путать его с паролем пользователя root).
2. 2.
   Перейдите в раздел «Доменные имена».
3. 3.
   Нажмите на Создать новый домен.
4. 4.
   В поле «Имя домена» введите имя добавляемого вами домена.
5. 5.
   В поле «IP первичного NS» введите IP-адрес вашего выделенного сервера.
6. 6.
   Нажмите ОК.
7. 7.
   Повторите операцию добавления домена на втором сервере (https://ns6.hosting.reg.ru/manager/dnsmgr).

Интерфейс управления первичным сервером имён

Если вы не хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления первичным сервером имен:

1. 1.
   Зайдите в панель управления DNS Admin, используя логин вида d0000000 и пароль для доступа к DNS (не следует путать его с паролем пользователя root).
2. 2.
   Перейдите в раздел «Доменные имена».
3. 3.
   Нажмите на Создать новый домен.
4. 4.
   В поле «Доменное имя» введите имя добавляемого вами домена.
5. 5.
   В поле «IP-адрес» введите IP-адрес вашего выделенного сервера;
6. 6.
   Нажмите ОК.

Создать свои собственные DNS-серверы на базе домена:

а) необходимо иметь основной IP вашего выделенного сервера и дополнительный, полученный при подключении услуги «Дополнительный IP адрес на ваш выбор»;

b) необходимо настроить свои DNS-серверы в ISPManager:

1. 1.
   Зайдите в вашу панель управления ISPmanager с правами администратора.
2. 2.

   Откройте раздел «Настройки DNS»:

3. 3.

   В поле «Серверы имён» укажите два DNS-сервера:, :

4. 4.
   Сохраните изменения.

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

c) У своего регистратора прописать для домена yourdomain.ru DNS-сервера: и , а также IP-адреса для каждого ns-сервера.

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

1. 1.
   Программа для записи музыки на cd и dvd

   Перейдите в . Кликните по строке домена, для которого хотите прописать ресурсную запись. В строке «DNS-серверы и управление зоной» нажмите Изменить:

2. 2.
   На открывшейся странице нажмите Добавить запись и выберите в шторке справа АААА.
3. 3.

   AAAA-запись аналогична A-записи: она связывает домен и IP-адрес сервера сайта. Отличие заключается в версии IP. А-запись предназначена для стандартных IPv4 (вида 123.123.123.123), а АААА-запись для современного сетевого протокола IPv6 (вида 7628:0d18:11a3:09d7:1f34:8a2e:07a0:765d).

   Чтобы добавить AAAA-запись, укажите в полях:

   Нажмите Готово:

2014: Передача функций контроля за управлением корневой зоной DNS от правительства США

В декабре 2014 года Межотраслевая рабочая группа ICANN подготовила предложения по передаче функций контроля за управлением корневой зоной DNS от правительства США интернет-сообществу. С инициативой передачи этих функций выступила весной нынешнего года Национальная администрация по телекоммуникациям и информации (NTIA), входящая в состав Министерства торговли США. Межотраслевая рабочая группа из 119 членов представила два варианта передачи функций.

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

Другой вариант предполагает создание новой структуры, надзирающей за деятельностью ICANN по управлению доменной системой и управляемой представителями интернет-сообщества. Авторы предложений подчеркивают, что речь идет о некоммерческой структуре с минимальным числом сотрудников. Таким образом, межотраслевая рабочая группа стремится, очевидно, избежать того, чего опасаются многие наблюдатели – создания «еще одной ICANN для надзора над ICANN».

Структура, условно обозначенная в документе как Contract Co, и возьмет на себя функции NTIA по контролю за управлением корневой зоной DNS. Выработка условий контракта с Contract Co и надзор за соблюдением его исполнения будут возложены на комитет Multistakeholder Review Team, сформированный из числа делегатов всех сообществ, чьи интересы представляет ICANN. Механизмы формирования этого комитета пока не определены и, вероятно, станут предметом жарких дискуссий, поскольку к максимальному представительству в нем будут стремиться самые разные группы с зачастую противоположными интересами.

Также будет сформирован новый постоянный комитет Customer Standing Panel, куда войдут представители регистратур общих и национальных доменов верхнего уровня – как главные «потребители услуг» корневой зоны DNS. Он будет транслировать комитету Multistakeholder Review Team пожелания регистратур, обеспечивая тем самым подотчетность ICANN перед ними. Наконец, предполагается и создание независимого апелляционного комитета, куда могут быть поданы жалобы на любые решения, связанные с управлением корневой зоной DNS, включая, очевидно, и решения о делегировании либо снятии с делегирования доменов.

Предложения опубликованы на сайте ICANN, комментарии к ним принимаются до 22 декабря 2014 года. Окончательное предложение правительству США по передаче функций контроля над управлением корневой зоной DNS должно быть сформулировано летом 2015 года.

Бесплатный DNS хостинг от компании 1Cloud

Об услугах 1Cloud я так же подробно писал ранее — https://moonback.ru/page/obzor-1cloud. Компания имеет ЦОДы в России, Казахстане и Белоруссии, предлагает широкий спектр услуг: виртуальные серверы, виртуальный ЦОД, объектное хранилище, облачная платформа Microsoft Azure, Amazon Web Services, защита от DDOS, SSL сертификаты и DNS хостинг.

Последний предлагается совершенно бесплатно, не зависимо от того пользуетесь ли вы другими услугами 1Cloud.ru или нет.

Услуга «DNS-хостинг» позволяет управлять ресурсными записями доменов, делегированных на DNS серверы 1Cloud.ru. Это бесплатный инструмент, который позволяет редактировать следующие ресурсные записи для доменного имени:

• A (IPv4 Address Record — адресная запись) — связывает доменное имя с IPv4-адресом хоста
• AAAA (IPv6 Address Record) — связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
• CNAME (Canonical Name Record — каноническая запись имени) — используется для перенаправления на другое доменное имя
• MX (Mail Exchange — почтовый обменник) — ссылается на почтовый сервер, обслуживающий домен
• NS (Name Server — сервер имен) — ссылается на DNS сервер, ответственный за домен
• TXT — текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
• PTR (Point to Reverse — запись указателя) — связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Вы также можете управлять представленными выше ресурсными записями через API.

Проверка регистрации записи ресурса

Конечный контроллер домена использует запись ресурса DNS-псевдонима (CNAME) для указания партнера по репликации исходного контроллера домена. хотя контроллеры домена, работающие Windows server (начиная с Windows server 2003 с пакетом обновления 1 (sp1)), могут обнаружить исходные партнеры репликации с помощью полных доменных имен или, если это не удается, ожидается, что NetBIOS-намессе запись ресурса псевдонима (CNAME) будет проверяться на предмет правильной работы DNS.

Для проверки регистрации записей ресурсов, включая регистрацию записи ресурса псевдонима (CNAME), можно использовать следующую процедуру.

Проверка регистрации записи ресурса

1. Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка.
2. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить. С помощью средства Dcdiag можно проверить регистрацию всех записей ресурсов, необходимых для расположения контроллера домена, выполнив команду.

Эта команда проверяет регистрацию следующих записей ресурсов в DNS:

• псевдоним (CNAME): запись ресурса на основе глобального уникального идентификатора (GUID), которая находит партнера репликации.
• узел (A): запись ресурса узла, которая содержит IP-адрес контроллера домена.
• Записи ресурсов LDAP SRV: службы (SRV), которые находят LDAP-серверы.
• GC SRV: записи ресурсов службы (SRV), которые находят серверы глобального каталога
• PDC SRV: записи ресурсов службы (SRV), которые находят хозяева операций эмулятора основного контроллера домена.

Для проверки регистрации записи ресурса псевдонима (CNAME) можно использовать следующую процедуру.

Проверка регистрации записи ресурса псевдонима (CNAME)

1. Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
2. Используйте оснастку DNS, чтобы выбрать любой контроллер домена, на котором работает служба DNS-сервера, где на сервере размещается зона DNS с тем же именем, что и домен Active Directory контроллера домена.
3. В дереве консоли щелкните зону с именем _msdcs. Dns_Domain_Name.
4. В области сведений убедитесь, что имеются следующие записи ресурсов: запись ресурса псевдонима (CNAME) с именем Dsa_Guid. _msdcs. Dns_Domain_Name и соответствующую запись ресурса узла (a) для имени DNS-сервера.

Если запись ресурса псевдонима (CNAME) не зарегистрирована, убедитесь, что динамическое обновление работает правильно. Используйте тест в следующем разделе, чтобы проверить динамическое обновление.

PTR-запись

Запись PTR (pointer), или запись указателя, связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse-форме вернет имя (FQDN) данного хоста.

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

Данная запись применяется при создании обратной DNS-зоны.

При создании записи можно указать следующие параметры:

• PTR — IP-адрес хоста в зоне in-addr-arpa;
• имя хоста — имя хоста, расположенного на данном IP-адресе.

Нажмите «Добавить» — созданная запись появится в списке.

Обратный DNS-запрос

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

2019

ICANN обеспокоена угрозой безопасности ключевых элементов интернета

Ключевые элементы инфраструктуры мирового интернета находятся под угрозой масштабных кибератак. Об этом сообщили представители корпорации ICANN информагентству Agence France-Presse (AFP) 22 февраля.

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

По данным старшего аналитика FireEye в области кибершпионажа Бена Рида (Ben Read), атаки под названием DNSpionage начались в 2017 году. Атакующие в основном перехватывают учетные данные регистраторов доменных имен и интернет-провайдеров в странах Среднего Востока. За атаками предположительно стоят иранские хакеры, действующие в интересах иранского правительства.

С 1 февраля 2019 года многие сайты в интернете станут недоступными

Ряд DNS-сервисов и производителей DNS-серверов объявили в январе 2019 года о проведении дня корректной обработки DNS-запросов или так называемого «Дня флага» (Flag Day). В этот день, намеченный на 1 февраля 2019 года, участники инициативы откажутся от реализации обходных путей для авторитативных DNS-серверов без поддержки протокола EDNS. К указанной дате каждый участник инициативы реализует соответствующие изменения в определенной версии своего ПО.

В случае с BIND 9 обходные пути будут закрыты в версии BIND 9.14.0, запланированной к выпуску на 1 февраля. Нововведение уже доступно для ветки 9.13, но не будет портировано на 9.11 или более ранние ветки BIND, поскольку, согласно политике компании, в стабильные версии с продленной поддержкой изменения не вносятся. В авторитативном (первичном) DNS-сервере BIND поддержка протокола EDNS уже реализована.

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

Операторам авторитативных DNS-серверов рекомендуется проверить свои системы на совместимость с EDNS на сайте https://dnsflagday.net/ . Пользователи BIND 9 могут не беспокоиться, поскольку, как уже упоминалось выше, DNS-сервер уже совместим с EDNS.

Windows серверов 2000 и Windows Server 2003, не в составе

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

Ключевые характеристики DNS

DNS обладает следующими характеристиками:

• Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.
• Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
• Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
• Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.