Описание протокола DNS (Domain Name System). DNS Службы и Протокол

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

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

Система доменных имен является одной из фундаментальных технологий современной интернет-среды, так как информация об IP-адресе запрашиваемого узла - обязательное условие получения ответа на любой интернет-запрос. Но IP-адрес представляет собой числовое значение вида "1.23.45.67", неподходящее для комфортного восприятия человеком. К тому же основной принцип распределения IP-адресов в сети - уникальность. Важно и то, что сетевой адрес - не самый устойчивый параметр. Он может изменяться (напр., при смене хоста, обслуживающего запрашиваемый узел, смене хостинг-провайдера, и т.п.). Все перечисленные особенности делают систему навигации по сетевым адресам сложной для человека.

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

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

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

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня ".com"), а также подчиненные ему узлы (напр., домен второго уровня "example.com", домен третьего уровня "mail.example.com" и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие "уровень" - показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

  • "." - домен нулевого уровня
  • ".ru" - домен первого (верхнего) уровня
  • "example.com" - домен второго уровня
  • "mail.example.com" - домен третьего уровня
  • Этот список можно продолжать

Обратите внимание на домен нулевого уровня "." (dot - точка) , также называемый корневым. На практике точку обычно не указывают ("example.com" вместо "example.com."), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце - полностью определенным (FQDN - Fully Qualified Domain Name) .

Доменная зона - часть иерархического дерева доменных имен (напр. ".ru"), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены ("anyaddress.ru", "any.anyaddress.ru").

Делегирование - передача ответственности за определенную ветвь дерева доменных имен другому физическому или юридическому лицу. Именно эта процедура практически реализует важный принцип работы DNS - распределенность хранения записей и обработки запросов. Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны (".ru"), так называемых "склеивающих" ("glue") NS-записей для делегируемой дочерней зоны ("example.com"), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня "example.com" и всех его дочерних доменов (например, "mail.example.com" и т.д.) хранятся на DNS-серверах этой компании, а родительская зона ".ru" хранит только указывающие на эти сервера NS-записи.

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

DNS-клиент - набор программных средств для работы с DNS. Сам DNS-сервер периодически также выступает в качестве клиента.

Основные типы ресурсных записей

Ресурсная запись (RR - Resource Record) - единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

  • Имя (Name) - имя домена, к которому относится запись
  • TTL (Time To Live) - допустимое время хранения записи неответственным сервером
  • Тип (Type) - параметр, определяющий назначение и формат записи в поле данных (Rdata)
  • Класс (Class) - тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
  • Длина поля данных (Rdlen)
  • Поле данных (Rdata) - содержание и формат поля зависят от типа записи

Ниже представлены типы ресурсных записей, используемые чаще всего:

  • 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-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Рекурсивные и нерекурсивные DNS-запросы

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

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

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

Протокол DNS выполняет две основные функции. Он позволяет клиентским компьютерам запрашивать DNS-сервер об IP-адресе или имени какого-либо хоста в сети, а также позволяет производить обмен информацией между базами данных серверов DNS. В этом протоколе используется стандартный формат типа "запрос-ответ", где клиент посылает пакет запроса, и сервер отвечает либо пакетом с информацией, полученной из базы данных, либо сообщением об ошибке, в котором указывается причина отказа в обработке запроса. В своей работе этот протокол использует порт 53 и хорошо известные протоколы - TCP или UDP. Причем в последнее время UDP стал более распространенным методом транспортировки пакетов по сети Internet. Пакет DNS состоит из пяти полей: заголовка, вопроса, ответа, полномочий и поля дополнительной информации. На рис. 4.5 показана общая структура пакета DNS.


Рис. 4.5.

Поле заголовка

В поле заголовка содержится информация о пакете и его назначении. В нем дается общее описание пакета (пакет запроса или пакет ответа) и указывается количество данных, содержащихся в каждом поле данных пакета. Описание заголовка приводится в табл. 4.3 .

Таблица 4.3. Поле заголовка DNS-пакета
Бит Описание
0-15 ID
16 QR
17-20 OPCODE
21 AA
22 TC
23 RD
24 RA
25-27 Z
28-31 RCODE
32-47 QDCOUNT
48-63 ANCOUNT
64-79 NSCOUNT
80-95 ARCOUNT

Биты ID являются уникальным 16-битовым идентификационным номером пакета запроса. Пакет ответа, формируемый сервером, также использует этот идентификационный номер, чтобы клиент мог сопоставить ответ сервера со своим запросом. Бит QR обозначает тип пакета (пакет запроса - 0, пакет ответа - 1). Поле OPCODE определяет тип запроса - стандартный (0), обратный (1) или запрос о статусе сервера (2).

Следующие четыре бита определяют различные параметры пакета. Бит AA устанавливается, когда ответ является авторитетным (данные поступают напрямую от DNS-сервера, ответственного за зону). Неавторитетные ответы могут поступать от серверов DNS, в кэше которых сохранилась информация об исходных записях от предыдущих запросов. Эта информация считается неавторитетной, так как есть вероятность, что с момента последнего обращения к серверу информация была изменена. Бит TC устанавливается, когда требуется урезать данные в пакете до вида, удобного для передачи по сети. Такое вполне возможно при использовании протокола UDP, согласно которому размер пакета не должен превышать 512 байт. Бит RD включается, когда клиент желает рекурсивно запрашивать DNS-сервер на постоянной основе. Если этот бит установлен, то DNS-сервер будет запрашивать другие DNS-серверы, пока не получит ответ. Если этот бит не установлен, то DNS-сервер будет возвращать на запрос любую информацию, которая у него имеется. Бит RA устанавливается, чтобы уведомить клиента о возможности рекурсивного запроса на данный сервер. Биты Z в настоящее время не используются и зарезервированы на будущее.

Биты RCODE используются только в пакетах ответов. Они отображают состояние ответа - без ошибок (0), ошибки в пакете запроса (1), внутренние ошибки не дали возможности серверу обработать запрос (2), имя, указанное в запросе, не существует (3), данный тип запроса не поддерживается сервером (4) и сервер отказался обработать запрос (5).

Остальные четыре параметра заголовка представляют собой 16-битовые числа и используются в качестве счетчиков. С их помощью ведется учет количества исходных записей, возвращаемых в пакете. QDCOUNT отображает количество запросов (в пакет может включаться более одного запроса). ANCOUNT - количество исходных записей, включенных в ответ. NSCOUNT обозначает число исходных записей об авторитетных серверах имен, а ARCOUNT - число записей в поле дополнительной информации.

Поле вопроса

Поле вопроса содержит запросы, ответы на которые клиент желает получить от DNS-сервера. В одном пакете DNS может содержаться несколько запросов. Количество запросов в пакете определяется параметром QDCOUNT из поля заголовка. Поле вопроса состоит из трех частей: списка преобразуемых доменных имен; поля типов записей, которые клиент желает получить в ответе, и параметра класса запроса. Список преобразуемых доменных имен представляет собой список имен, для которых клиент желает получить IP-адреса. Для формирования списка имен используется специальный формат. Перед каждым именем ставится однобайтное значение, которое определяет длину имени. Конец списка обозначается именем с нулевой длиной. После текстовой части следует двубайтная запись QTYPE . В ней определяется, в каком виде клиент желает принимать информацию о имеющихся доменах. Эти значения полностью соответствуют типам исходных записей в DNS. Например, для того чтобы найти почтовый сервер для определенного домена, вам следует воспользоваться типом записи МХ . И, наконец, последний параметр в поле вопроса - QCLASS . Он определяет класс запроса, который в нашем случае для сети Internet всегда будет IN .

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

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

Кто управляет и поддерживает DNS-сервера?

Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.

Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.

Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.

После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.

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

Доменное имя состоит, по меньшей мере, из двух частей (меток), разделенных точками. Нумерация меток ведется справа налево.. Все последующие метки - поддомены, т.е. hosting - поддомен домена web-3, а web-3 - домена ru.

Условно подобное деление может растянуться на 127 уровней. Любая метка может состоять (максимально) из 63 символов, но длина доменного имени не может быть больше 254 знаков, включая точки. Впрочем, действительность и теория, как известно, - разные вещи, посему регистраторы доменов часто устанавливают собственные лимиты.

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

Для передачи данных посредством стека протоколов TCP/IP необходимо знать IP-адрес указанного сервера, но тот, как правило, имеет лишь сведения об адресе сервера DNS (обычно интернет-провайдер предоставляет адрес одного основного и одного резервного DNS-сервера).. Тот, в свою очередь, запрашивает информацию у центрального сервера, например 195.42.0.3 (все IP-адреса приведены в качестве примера и могут отличаться от действительных). Сервер отвечает, что не обладает информацией о требуемом адресе, однако, знает, что доменной зоной.ru занимается сервер 214.74.142.1 (прим. ред. Это так называемый авторитетный сервер). В этом случае сервер DNS запрашивает информацию у 214.74.142.1. Ответом может быть: «web-3.ru занимается сервер 247.142.130.234». Этот третий по счету сервер возвращает браузеру IP-адрес нужного сайта (прим. ред. Очень часто рекурсивный подход заменяется запросами к буферу сервера. Если неавторитетный сервер недавно получал запрос на IP адрес сайт, то вместо обращения к следующему DNS серверу он выдаст результат из буфера. ).

Для реагирования на запрашиваемую информацию DNS-протокол применяет UDP- или TCP-порт 53. Обычно запросы и готовая информация по ним посылаются в форме UDP-датаграммы. А TCP остается для AXFR-запросов или ответов весом более 512 байт. Для того чтобы узнать IP-адрес интересующего вас сайта, необходимо воспользоваться командой ping. Если вы пользуетесь операционной системой Windows XP, нажмите «Пуск»- «Выполнить» (прим. ред. Сочетание клавиш win+r) и наберите в строке команду cmd . Появится окошко командной строки. В ней наберите команду ping и имя сайта, например, ping сайт. В строчках, которые появятся после нажатия Enter увидите группу чисел 87.242.76..

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

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

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

Известно доменное имя in-addr.arpa, данные которого служат для реконструирования IP-адреса в имя из символов. Приведем пример: чтобы выяснить имя известного адреса (предположим, 12.13.14.15) допустимо сделать запрос в следующем виде: 15.14.13.12.in-addr.arpa. Результатом окажется должное символьное имя. Чем можно это объяснить? Тем, что в IP-адресах биты, расположенные у корня, стоят в начале, а в DNS-именах – в конце.

Что касается записей DNS, то выделяют несколько категорий:

  1. Address record (запись А) служит для связи адреса IP и хоста.
  2. Canonical name record (сокращенно CNAME, каноническая запись имени) – инструмент переадресации на альтернативное имя.
  3. Mail exchange (МХ, почтовый обменник) ссылается на сервер обмена почтой для представленного домена.
  4. PTR (pointer, или запись указателя) соединяет имя хоста с его установленным (каноническим) именем.
  5. NS (name server) называет DNS-сервер представленного доменного имени.
  6. SOA (start of authority record) – запись, ссылающаяся на тот сервер, который содержит стандартные сведения о представленном домене.

Необходимо сказать о зарезервированных доменах (Reserved Top Level DNS Names). Документ RFC 2606 указывает на те имена доменов, которые нужно применять в роли модели (что особенно важно в документации) и при тестировании. В качестве примера можно привести test.com, test.org, test.net, а также invalid, example и т.д.

В разговоре о доменных именах стоит упомянуть о том, что они могут состоять из небольшой комплектации ASCII символов. Это делает возможным набор доменного адреса вне зависимости от того языка, на котором говорит пользователь. Потому такие имена – интернациональные. ICANN ратифицировал систему IDNA, базирующуюся на Punycode. Она способна конвертировать всякую фразу в кодировке Unicode в тот набор знаков, который будет возможен для корректной работы DNS.

Некоторые способы действия приложения DNS применяются в BIND (Berkeley Internet Name Domain), MaraDNS NSD (Name Server Daemon), DJBDNS (Daniel J. Bernstein"s DNS), PowerDNS Microsoft DNS Server (в серверных вариантах операционных систем Windows NT).

Чтобы узнать, кто владеет каким-либо доменом или IP-адресом достаточно использовать возможности сетевого протокола whois (от англ. who is - «кто?»). Первоначальной идеей, положившей начало созданию данной системы, было стремление не позволять системным администраторам находить данные иных администраторов IP-адресов и доменов. Ныне доменное имя признается незарегистрированным на определенное имя, пока нельзя найти общедоступные сведения о нем в этом сервисе.

DNS (Domain Name System - система доменных имён) - компьютерная распределённая система преобразование символьного имени (сайт) в IP-адрес (91.106.203.89) и наоборот.

DNS была разработана Полом Мокапетрисом в 1983 году.

В сети интернет DNS выполняет важную задачу, для доступа к веб-серверу необходимо знать его IP-адрес. Необходимость использования DNS обусловлена тем, что людям легче запоминать буквенные (обычно осмысленные) адреса, чем последовательность четырех цифр IP – адреса, компьютерам, в свою очередь, удобнее обрабатывать численное представление адреса (IP-адрес). Также наличие символьного имени сервера позволяет использовать так называемые виртуальные серверы , например, HTTP-серверы, отличающиеся друг от друга именем запроса (доменным именем), но использующие один и тот же IP-адрес.

В начале для преобразования IP-адресов в символьные имена использовался текстовый файл hosts , расположенный:

  • В Windows: %SystemRoot%\system32\drivers\etc\hosts;
  • В Unix: /etc/hosts;

Пример файла hosts в Windows

Файл hosts заполнялся автоматически и централизовано на каждой ЭВМ в своей локальной вычислительной сети. Но даны подход со временем показал свою не-состоятельность, поскольку с ростом сети, количество записей в текстовом файле увеличивалось, как следствие увеличивался размер файла, ко всему прочему частая пересылка файла hosts загружала вычислительную сеть.

В итоге стала необходимость в разработке автоматизированного механизма, которым и стала распределенная система DNS.

Следует учесть, что файл hosts используется до сих пор, в частности, при настройке локального сервера на ЭВМ, в hosts записываются созданные локальные символьные имена. Например:

  • 127.0.0.1 mysite.local

Иерархия имен в DNS

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

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

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

Иерархия доменных имен начинается с корневого домена без имени (или еще как его называют «домен точка»), далее идут домены верхнего уровня или домены первого уровня. Домены верхнего уровня поделены на три зоны:

  • arpa это специальный домен, используемый для сопоставления адрес - имя
  • Семь трехсимвольных доменов называются общими (generic) доменами или организационными (organizational) доменами.
  • Двухсимвольные домены, так называемые домены стран или географические домены (ru – Российская федерация, kz - Казахстан), основанные на кодах стран, в соответствии с ISO 3166.

Поскольку DNS поддерживает иерархию доменных имен, но никак не IP-адресов. Для решения “обратной” задачи есть специальный домен, структура которого совпадает со структурой IP-адресов. Называется этот домен IN-ADDR.ARPA .

in-addr.arpa - специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Имена в домене IN-ADDR.ARPA образуют иерархию цифр, которые соответствуют IP-адресам. Правда, записываются эти имена в обратном порядке относительно написания IP-адреса.

Например, доменное имя сайт, которое имеет адрес 91.106.203.89 должна быть описана в домене in-addr.arpa как 89.203.106.91.in-addr.arpa, то есть адрес записывается в обратном порядке.

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

Основные типы записей используемые в протоколе DNS

    • A запись (address record IPv4) или запись адреса - основная запись, выполняет связующую роль между именем хоста (сайт) и IP адресом (5.101.153.37). Если меняется только А запись, то это значит, что наш сайт физически будет размещен на другом хостинге, а все остальные записи останутся работать на старом хостинге.
    • CNAME запись (canonical name record) или каноническая запись имени (псевдоним) - используется для перенаправления на другое имя (по аналогии с ссылками), частным примером использования CNAME записи, является создание доменных имен для ftp, mail, ssh, например
    • NS запись (name server) указывает на DNS сервер текущего домена, так называемые authoritative DNS-серверы. Смена NS-записи, при переходе на другой хостинг, всечёт за собой смену всех записей, соответственно нужно или указывать новые записи или копировать со старого сайта (например, для сохранения почты, нужно скопировать MX-запись со старого хостинга). При неправильном изменении NS записи домена, может привести к остановке работы сайта.