Основы сети. Часть 5. DNS.
____________________________________________________________________________________
Глава 5. DNS.
- ЧТО ТАКОЕ DNS.
- ИЕРАРХИЯ ДОМЕНОВ.
- DNS-СЕРВЕРЫ.
- ПРОТОКОЛ DNS (КАК РАБОТАЕТ DNS).
- DNS-ЗОНЫ (ДОМЕННЫЕ ЗОНЫ).
- РАСПРЕДЕЛЕНИЕ ДОМЕНОВ.
- DNS-ЗАПИСИ.
____________________________________________________________________________________
§ 5.1. ЧТО ТАКОЕ DNS.
5.1.1) DNS (DOMAIN NAME SYSTEM) — это система доменных имен, которая преобразует IP-адреса в доменные имена. DNS является протоколом TCP/IP.
DNS использует UDP-порт 53 и TCP-порт 53. По умолчанию используется UDP, а при невозможности обмена данными по UDP, используется TCP (это, как правило, происходит, когда размер пакета данных слишком велик для передачи в одном UDP-пакете).
DNS является неотъемлемой частью Интернета и простым способом связи устройств в Интернете без запоминания сложного IP-адреса. Каждое устройство в Интернете имеет уникальный IP-адрес для связи с ним, и чтобы с этим IP-адресом было удобно работать, DNS преобразует IP-адрес в удобное доменное имя. И например, при посещении сайта вместо его IP-адреса (192.0.2.1), можно использовать его доменное имя (google.com).
DNS также хранит и выводит дополнительную информацию об услугах, связанных с доменом. Например, с помощью DNS-запросов можно определить какой компьютер служит сервером электронной почты для домена или как называются серверы доменных имен.
DNS не имеет центральной базы данных. Информация распределена по многим тысячам серверов имен. Глобально распределенные DNS-серверы преобразуют доменные имена в IP-адреса и контролируют, к какому серверу пользователь может подключиться через определенный домен. Для пользователей DNS действует как интернет-навигатор, направляя нас от доменных имён к IP-адресам. Без DNS было бы много ошибок в навигации по Интернету.
ШИФРОВАНИЕ DNS. DNS по умолчанию не зашифрован, что позволяет взламывать и отслеживать устройства в локальной сети WLAN и интернет-провайдеры с помощью запросов DNS. Поскольку незашифрованный DNS создает угрозу конфиденциальности, есть несколько решений для шифрования DNS:
➤ DNS позволяет изменять сетевую инфраструктуру: если Яндекс с помощью DNS захочет перенести свой веб-сервер на другой компьютер с иным IP-адресом, то доменное имя www.yandex.ru при этом не изменится.
➤ С помощью DNS можно подключить несколько серверов (следовательно и IP-адресов) к доменному имени. Это нужно для разгрузки веб-сайта, когда на него идёт много запросов от юзеров. Если один сервер будет перегружен, запросы от юзеров перенаправятся на другой сервер. Получается, что у одного доменного имени может быть несколько IP-адресов.
➤ DNS является децентрализованной системой: нет единого сервера, где бы хранились все имена хостов; все компьютеры разделены на домены, за каждый домен отвечает отдельная организация.
5.1.3) Можно узнать IP-адрес домена сайта с помощью следующих инструментов:
5.1.4) ПОЧЕМУ DNS ВАЖЕН ДЛЯ ВЕБ-РАЗВЕДКИ:
- Обнаружение ресурсов: DNS-записи могут содержать огромное количество информации, включая поддомены, почтовые серверы и записи серверов имен. Например, CNAME-запись, указывающая на устаревший сервер, может привести к уязвимости системы.
- Составление карты сетевой инфраструктуры: можно создать полную карту сетевой инфраструктуры цели с помощью данных DNS. Например, идентификация серверов имен (NS-записи) для домена может выявить используемого хостинг-провайдера, A-запись может определить балансировщик нагрузки. Это поможет нам понять, как связаны различные системы, определить потоки трафика и слабые места, которые можно использовать во время теста на проникновение.
- Мониторинг изменений: постоянный мониторинг DNS-записей может выявить изменения в целевой инфраструктуре с течением времени. Например, внезапное появление нового поддомена может указывать на новую точку входа в сеть, а TXT-запись, содержащая значение типа «_1password=...» убедительно указывает на то, что организация использует 1Password, который можно использовать для социальной инженерии или фишинговых атак.
§ 5.2. ИЕРАРХИЯ ДОМЕНОВ.
5.2.1) КОРНЕВОЙ ДОМЕН — это домен 0-го уровня. Этот домен не отображается в URL-адресе сайта.
Корневой сервер DNS. Данные сервера перенаправляют клиента на правильный сервер домена верхнего уровня. Например, если клиент запросит домен www.yandex.ru, то сервер корневого уровня направит к серверу верхнего уровня, работающего с адресами .ru
5.2.2) ДОМЕН ВЕРХНЕГО УРОВНЯ (TLD) — это самая правая часть доменного имени. Серверы TLD хранят записи о том, где найти искомый домен 2-го уровня для клиента. Авторизованный сервер также называют сервером имен для домена.
Типы доменов верхнего уровня (TLD):
I) gTLD — общий домен верхнего уровня. Используется для обозначения целей сайта:
- .com — для коммерческих целей;
- .org — для организации;
- .edu — для образования;
- .gov — для правительства;
II) ccTLD — домен верхнего уровня с кодом страны. Используется для обозначения географической области веб-сайта:
Полный список доменов верхнего уровня — https://data.iana.org/TLD/tlds-alpha-by-domain.txt
5.2.3) ДОМЕН ВТОРОГО УРОВНЯ — на этом уровне уже записывается уникальное имя сайта (google, yandex, yahoo). При регистрации, домен 2-го уровня ограничен 63 символами и может использовать только: символы a–z, цифры 0–9 и дефисы (дефисы нельзя записывать в начале, в конце или повторять друг за другом).
5.2.4) ДОМЕН ТРЕТЬЕГО УРОВНЯ (ПОДДОМЕН) — является частью основного домена, который создаётся для разделения различных функций веб-сайта. Например, в домене «yandex.com» может использоваться поддомен «blog.yandex.com» для блога, а поддомен «shop.yandex.com» для интернет-магазина.
Поддомены обычно имеют свои собственные DNS-записи, указывая либо на IP-адрес основного домена, либо на другой IP-адрес.
- Общедоступные поддомены — это поддомены, которые записаны либо в общедоступном DNS-сервере, либо в нашем локальном файле /etc/hosts.
- Частные поддомены — это поддомены, которые не записаны ни в общедоступном DNS-сервере, ни в нашем локальном файле /etc/hosts. Если запись о поддомене отсутствует в обоих местах, то браузер не будет знать, как к нему подключиться. Чтобы подключиться к частному поддомену, нужно записать его в файле /etc/hosts.
При регистрации, домен 3-го уровня ограничен 63 символами и может использовать только: символы a–z, цифры 0–9 и дефисы (дефисы нельзя записывать в начале, в конце или повторять друг за другом).
Разрешается использовать несколько поддоменов (admin.support.hohol.com). Можно создавать неограниченное количество поддоменов для доменного имени.
§ 5.3. DNS-СЕРВЕРЫ.
I) КОРНЕВОЙ СЕРВЕР DNS (DNS ROOT SERVER) — это центральный интерфейс между пользователями и контентом в Интернете, который связывает IP-адрес и домен. Корневой сервер отвечает за домены верхнего уровня (TLD).
Корневых серверов DNS всего 13 по всему миру. Их работу координирует интернет-корпорация ICANN.
II) АВТОРИТЕТНЫЙ СЕРВЕР ИМЕН (AUTHORITATIVE NAMESERVER) — это сервер, который обслуживает определенную DNS-зону. Он отвечает только на запросы из своей области ответственности, и его информация является обязательной.
III) НЕАВТОРИТЕТНЫЙ СЕРВЕР ИМЕН (NON-AUTHORITATIVE NAMESERVER) — это сервер, который не несёт ответственности за определенную DNS-зону. Вместо этого он собирают информацию о самих DNS-зонах с помощью рекурсивных или итерационных DNS-запросов.
IV) КЭШИРУЮЩИЙ DNS-СЕРВЕР — это сервер, который кэширует информацию с других серверов имен в течение определенного периода времени. Срок хранения определяет авторитетный сервер имен.
V) ПЕРЕНАПРАВЛЯЮЩИЙ DNS СЕРВЕР — это сервер, который выполняет только одну функцию: они переадресовывают DNS-запросы на другой DNS-сервер.
VI) DNS-ПРЕОБРАЗОВАТЕЛЬ (DNS RESOLVER) — это компонент инфраструктуры DNS, который преобразует доменные имена в IP-адреса. Выполняется это действие локально на компьютере или маршрутизаторе.
5.3.2) НАСТРОЙКИ DNS-СЕРВЕРА. Все DNS-серверы работают с тремя типами файлов конфигурации:
В системах Linux очень часто используется локальный DNS-сервер Bind 9, поэтому настройки DNS-сервера будет рассматривать на его основе. Установить Bind 9 можно с помощью команды:
Более подробно о DNS-сервере Bind 9 можно почитать в его документации.
I. Файлы конфигурации локального DNS-сервера. Файл конфигурации Bind 9 расположен в /etc/bind/named.conf:
Файл конфигурации named.conf разделен на параметры, которые управляют поведением сервера имён. Разливают между глобальные параметры и параметры зоны.
Глобальные параметры являются общими и влияют на все параметры зоны. Параметр зоны влияет только на зону, которой этот параметр назначен. Параметры, не перечисленные в файле named.conf, имеют значения по умолчанию. Если параметр является как глобальным, так и специфичным для конкретной зоны, то приоритет имеет параметр зоны.
В каталоге /etc/bind/ есть также файл named.conf.local, в котором можно определить различные зоны:
Зоны разделены на отдельные файлы, которые в большинстве случаев предназначены в основном только для одного домена. Исключением являются интернет-провайдеры и общедоступные DNS-серверы. Кроме того, многие различные параметры расширяют или уменьшают функциональность
II. Файлы DNS-зон. Это текстовый файл, который описывает DNS-зону в формате файла BIND (формат файла BIND широко используется в программном обеспечении DNS-серверов).
Файл DNS-зон расположен в /etc/bind/db.имяДомена:
Файл зоны полностью описывает зону. В этом файле должна быть только одна SOA-запись и хотя бы одна NS-запись. SOA-запись обычно располагается в начале файла зоны. В файле зоны все пересылаемые DNS-записи приводятся в соответствии с форматом BIND. Это позволяет DNS-серверу определить, какой домен, имя хоста и роль принадлежат IP-адресам.
Основной целью правил выше является улучшение читаемости файлов зон. Синтаксическая ошибка в файле зоны обычно приводит к тому, что весь файл зоны становится непригодным для использования. Сервер имён будет вести себя так, как будто этой DNS-зоны не существует, на запросы DNS он будет отвечать сообщением об ошибке (SERVFAIL).
III. Файлы обратного просмотра доменных имён. Этот файл нужен для того, чтобы DNS-сервер мог определить IP-адрес по его полному доменному имени. В этом файле имя компьютера (FQDN) присваивается последнему октету IP-адреса, который соответствует соответствующему хосту, используя PTR-запись (эта запись отвечают за обратный перевод IP-адресов в доменные имена).
Файл обратного просмотра доменных имён расположен в
/etc/bind/db.последнийОктетIPадреса:
5.3.3) УЯЗВИМЫЕ НАСТРОЙКИ DNS-СЕРВЕРА.
Существует много способов атак на DNS-сервер. Например, список популярных атак на DNS-серверы можно найти в SecurityTrails. Список уязвимостей для конкретного DNS-сервера Bind 9 можно найти в CVEdetails.
Поскольку система DNS может быть очень сложной, то в ней могут быть ошибки, заставляя администраторов работать над устранением проблем, пока они не найдут точное решение. Это часто приводит к высвобождению элементов, чтобы части инфраструктуры функционировали в соответствии с планом и желаниями. В таких случаях функциональность имеет более высокий приоритет, чем безопасность, что приводит к неправильным настройкам и уязвимостям.
- allow-query — определяет, каким хостам разрешено отправлять запросы на DNS-сервер.
- allow-recursion — определяет, каким хостам разрешено отправлять рекурсивные запросы на DNS-сервер.
- allow-transfer — определяет, каким хостам разрешено получать передачу зон с DNS-сервера.
- zone-statistics — собирает статистические данные о зонах.
§ 5.4. ПРОТОКОЛ DNS (КАК РАБОТАЕТ DNS).
5.3.1) ПРОТОКОЛ DNS — работает в режиме "запрос-ответ" (клиент-сервер, клиентский сервер-сервер). DNS использует протокол UDP.
ЭТАП 1. Клиент отправляет серверу корневого домена запрос с предоставлением доменного имени taxi.yandex.ru.
Но до этого момента, клиентский браузер сначала проверяет свой локальный кеш (память компьютера) с сохраненными доменными именами на наличие искомого домена.
Если в кеше компьютера нет нужного домена, то направляется запрос к рекурсивному DNS-серверу, который предоставляется нашим интернет-провайдером (пункт 5.3.3). Рекурсивный DNS-сервер тоже имеет локальный кэш с сохраненными доменами. Если искомого домена в кеше нет, то запрос направляется к серверу корневого домена.
ЭТАП 2. Корневой сервер отвечает, что ответ надо искать у сервера, ответственного за домен 1-го уровня ru (TLD).
ЭТАП 3. Клиент отправляет серверу домена 1-го уровня ru запрос с предоставлением доменного имени taxi.yandex.ru.
ЭТАП 4. Cервер домена 1-го уровня ru отвечает, что ответ надо искать у сервера, ответственного за домен 2-го уровня (в нашем случае, это сервер yandex.ru).
ЭТАП 5. Клиент отправляетсерверу домена 2-го уровня (yandex.ru) запрос с предоставлением доменного имени taxi.yandex.ru.
ЭТАП 6. Cервер домена 2-го уровня yandex.ru сообщает клиенту IP-адрес домена taxi.yandex.ru. Наш компьютер кэширует этот IP-адрес на некоторое время.
ЭТАП 7. Теперь, когда клиентский компьютер знает целевой IP-адрес, он может напрямую подключиться к веб-серверу, на котором размещен веб-сайт taxi.yandex.ru.
- Итеративный режим: если DNS-сервер отвечает за конкретную доменную зону, в которой находится нужный клиенту домен, то сервер возвращает ответ. Если нет, то отправляет клиенту адрес другого DNS-сервера, в котором находится нужный клиенту домен.
В итеративном режиме работают DNS-сервера доменов корневого уровня и 1-го уровня, так как к ним поступает огромное количество запросов от клиентов, а рекурсивный режим такую загруженность не выдерживает. - Рекурсивный режим: DNS-сервер сам выполняет запросы к другим DNS-серверам, чтобы найти нужный клиенту домен. Рекурсивный DNS-сервер автоматически известен маршрутизатору в нашей сети.
Рекурсивный DNS-сервер работают лично для клиентов: такой DNS-сервер получает запрос от клиента, затем самостоятельно ищет нужный домен и возвращают ответ обратно клиенту. Клиентский компьютер сам в это время "отдыхает".
Такой DNS-сервер предоставляется провайдером, ведь многие интернет-провайдеры поддерживают свои собственные рекурсивные серверы. Однако клиент может сам выбрать произвольный DNS-сервер, например, подключиться к открытым DNS-серверам Google (8.8.8.8 или 8.8.4.4).
DNS-ответ с IP-адресом искомого домена на таких серверах кэшируется. Это повышает скорость Интернета, ведь клиенту не нужно будет заново искать IP-адресом домена. Однако, IP-адрес домена может поменяться, а в кэше новый IP-адрес заменится через некоторое время.
5.4.4) ФАЙЛ ХОСТОВ — это простой текстовый файл для сопоставления имён хостов с IP-адресами, который предоставляет собой ручной метод преобразования доменных имен в обход протокола DNS.
С помощью файла хостов можно напрямую преобразовать доменные имена в IP-адреса. Файл хостов находится по адресу:
Каждая строка в файле хостов имеет следующий формат:
ФУНКЦИИ ФАЙЛА ХОСТОВ. Файл хостов может использоваться для следующих целей:
5.4.5) ТИПЫ ОТВЕТОВ ОТ DNS-СЕРВЕРОВ:
➤ Авторитетный (заслуживающий доверия) — ответ от сервера, обслуживающего доменную зону, в которой находится искомый домен или ответ, полученный из конфигурационных файлов на диске сервера.
➤ Неавторитетный (не заслуживающий доверия) — ответ от сервера, не обслуживающего доменную зону, в которой находится искомый домен или ответ, полученный из кэша DNS-resolver-а.
- QR — означает тип операции:
0 — запрос;
1 — ответ. - Opcode — означает тип запроса:
0 — стандартный запрос;
1 — инверсный запрос;
2 — запрос статуса сервера;
3-15 – зарезервированы на будущее. - AA — сообщает о том, является ли ответ авторитетным (1) или нет (0).
- TC — сообщает о том, был пакет обрезан (1) или нет (0).
- RD — этот флаг отправляется только в запросе; означает, что клиент просит сервер работать в рекурсивном режиме.
- RA — этот флаг отправляется только в ответе; означает, что сервер может работать в рекурсивном режиме.
- Z — зарезервировано для будущего использования
- RCODE — сообщает о статусе выполнения операции:
0 — успешно;
1 — сервер не смог понять форму запроса;
2 — некорректная работа сервера доменных имен;
3 — доменное имя, которое запрашивает клиент не существует в домене;
4 — сервер не может выполнить запрос данного типа;
5 — сервер не может удовлетворить запрос клиента в силу административных ограничений безопасности.
5.4.7) Форматы DNS-запроса и DNS-ответа:
§ 5.5. DNS-ЗОНЫ (ДОМЕННЫЕ ЗОНЫ).
5.5.1) DNS-ЗОНЫ (ДОМЕННЫЕ ЗОНЫ) — это отдельная часть пространства имён DNS, которой управляет определённая организация или администратор. Например, домен yandex.ru и все его поддомены (mail.yandex.ru, taxi.yandex.ru) обычно принадлежат одной и той же доменной зоне.
Поскольку DNS включает в себя несколько DNS-зон, то DNS-серверы используют передачу DNS-зон для копирования части своей базы данных на другой DNS-сервер.
Файл зоны в текстовом формате, расположенный на DNS-сервере, определяет записи ресурсов в этой зоне, предоставляя важную информацию для преобразования доменных имен в IP-адреса. Файл зоны может выглядеть следующим образом:
Файл зоны определяет авторитетные серверы имен (NS-записи), почтовый сервер (MX-запись) и IP-адреса (A-записи) для различных хостов внутри домена yandex.com.
Исходные данные зоны хранятся на DNS-сервере, который называется основным сервером имен для этой зоны. Однако для повышения надежности, реализации простого распределения нагрузки или защиты основного сервера от атак практически во всех случаях устанавливается один или несколько дополнительных серверов, которые называются вторичными серверами имен для этой зоны. Для некоторых доменов верхнего уровня (TLD) необходимо обеспечить доступ к файлам зон для доменов второго уровня как минимум на двух серверах.
Как правило, DNS-записи создаются, изменяются или удаляются только на основном сервере. Это может быть сделано путем ручного редактирования соответствующего файла зоны или автоматического динамического обновления из базы данных. DNS-сервер, который служит прямым источником для синхронизации файла зоны, называется ведущим. DNS-сервер, который получает данные о зоне от ведущего, называется подчиненным. Основной сервер всегда является ведущим, в то время как дополнительный может быть как подчиненным, так и ведущим.
5.5.2) ПЕРЕДАЧА DNS-ЗОНЫ (AXFR) — это полное копирование всех DNS-записей внутри DNS-зоны (домена и его поддоменов) с одного сервера имен (NS-сервер) на другой. Этот процесс нужен для поддержания согласованности и избыточности на DNS-серверах.
Хотя служба DNS по умолчанию работает через UDP-порт, однако при передаче DNS-зон она использует TCP-порт 53 для надёжности.
Поскольку сбой DNS обычно имеет серьезные последствия для компании, то файл зоны почти всегда остается идентичным на нескольких серверах имен. При внесении изменений в файл зоны необходимо убедиться, что все серверы содержат одинаковые данные. Синхронизация между задействованными серверами осуществляется путём переноса зоны. С помощью секретного ключа rndc-key, серверы гарантируют, что они общаются со своим собственным основным или вторичным сервером. Передача зоны включает в себя простую передачу файлов или записей и обнаружение расхождений в наборах данных задействованных серверов.
Однако, если DNS-сервер настроен неправильно (нет ограничений IP-адресов, которые могут выполнять передачу DNS-зон), то любой пользователь может запросить у DNS-сервера копию информации о DNS-зоне, поскольку передача DNS-зон не требует аутентификации.
Можно получить копию DNS-зоны из целевого DNS-сервера с помощью команды:
dig axfr серверИмен1 @серверИмен2
Мы запросили у одного сервера имён (10.129.14.128) передачу всех его записей на второй сервер имён (inlanefreight.htb).
Первый сервер имён (10.129.14.128) был связан с поддоменом, поэтому мы бы не смогли напрямую прочитать все его DNS-записи, поскольку он работает внутри целевой сети. А поскольку мы передали все его DNS-записи второму серверу имён (inlanefreight.htb), который является публичным, то поэтому мы и смогли прочитать все DNS-записи первого сервер имён.
ЭТАПЫ ПЕРЕНОСА DNS-ЗОНЫ:
ЭТАП 1. ЗАПРОС НА ПЕРЕНОС ЗОНЫ (AXFR-ЗАПРОС). Вторичный DNS-сервер отправляет запрос на перенос зоны на основной сервер. Обычно в этом запросе используется тип запроса AXFR (полный перенос зоны).
ЭТАП 2. ПЕРЕДАЧА SOA-ЗАПИСИ. Основной сервер отправляет свою запись о начале проверки подлинности (SOA-запись). SOA-запись содержит важную информацию о DNS-зоне, включая ее серийный номер, который помогает вторичному DNS-серверу определить, являются ли данные о зоне актуальными.
Вторичный сервер получает SOA-запись от основного сервера через определенные промежутки времени (время обновления), это обычно один час, и сравнивает серийные номера SOA-записей. Если серийный номер SOA-записи основного сервера больше, чем у вторичного, то в таком случае наборы данных больше не совпадают.
ЭТАП 3. ПЕРЕДАЧА DNS-ЗАПИСЕЙ. Основной сервер передаёт одну за другой все DNS-записи в зоне на вторичный сервер (A, AAAA, MX, CNAME, NS и другие записи).
ЭТАП 4. ЗАВЕРШЕНИЕ ПЕРЕДАЧИ DNS-ЗОНЫ. После передачи всех DNS-записей основной сервер отправит уведомление об окончании передачи зоны. Это уведомление сообщает вторичному серверу, что он получил полную копию данных зоны.
ЭТАП 5. ПОДТВЕРЖДЕНИЕ (ACK-ФЛАГ). Вторичный сервер отправляет на основной сервер подтверждающее сообщение об успешном получении и обработке данных зоны. На этом процесс переноса зоны завершается.
§ 5.6. РАСПРЕДЕЛЕНИЕ ДОМЕНОВ.
5.6.1) РАСПРЕДЕЛЕНИЕ ДОМЕНОВ — этой задачей занимаются регистраторы. Регистратором корневого домена является только одна организация — ICANN. Регистраторов же других уровней бесчисленное количество.
Регистраторы доменов первого уровня должны получить аккредитацию в ICANN, затем они могут регистрировать домены нижних уровней.
В России регистраторами доменов первого уровня являются такие организации:
5.6.2) РЕГИСТРАЦИЯ ДОМЕНОВ — платная услуга, доступная физлицам и юрлицам. Можно зарегистрировать домен в любой зоне 1-го уровня (ru, org, net и т.д.).
§ 5.7. DNS-ЗАПИСИ.
5.7.1) DNS-ЗАПИСИ — это записи, которые используются при реализации работы DNS. Каждая DNS-запись имеет:
- Тип записи — для чего предназначена запись.
- Класс записи — в каких сетях может использоваться запись.
- A — адресная запись, которая сопоставляет доменное имя с его адресом IPv4. На VDS можно настроить несколько A-записей, если у нас несколько веб-серверов, обрабатывающих запросы для одного домена. Такая запись называется round-robin. В этом случае преобразование доменного имени в IP-адрес производится в произвольном порядке с равной вероятностью распределения.
- AAAA — адресная запись, которая сопоставляет доменное имя с его адресом IPv6.
- CNAME — запись, которая позволяет присваивать домену каноническое имя для псевдонима (одноуровневая переадресация). Она служит для наследования одним доменом всех ресурсных записей другого домена, за исключением NS. Например, если необходимо, чтобы для test.mydomain.com были применены те же настройки DNS, что и для mydomain.com, необходимо указать mydomain.com в качестве CNAME-записи.
- DKIM-подпись — технология e-mail аутентификации, которая позволяет подтвердить подлинность отправителя. DKIM добавляет в сообщение цифровую подпись, удостоверяющую, что письмо действительно поступило с ящика на указанном домене. Наличие DKIM повышает доверие серверов-получателей к письму и тем самым снижает его шансы оказаться в папке «Спам» или вовсе быть отклоненным принимающим сервером. С нашей стороны DKIM-подпись может быть сгенерирована только для доменов, у которых указаны MX-серверы Timeweb.
- MX — запись, указывающая на адрес почтового сервера, ответственного за обработку электронной почты в домене. Данная запись состоит из двух частей: приоритета (чем число больше, тем ниже приоритет) и адреса узла.
- NS — указывает на DNS-сервер, которому делегирован домен. Этот тип записи показывает, какие серверы имён используются для преобразования полного доменного имени в IP-адрес. Большинство хостинг провайдеров используют свои собственные серверы имен, что облегчает идентификацию хостинг поставщика. Записи NSкритически важны для функционирования системы доменных имён.
- PTR — эта запись связывает IP-адрес с доменным именем. Многие почтовые серверы при фильтрации входящей почты от спама проверяют наличие PTR-записи и ее соответствие имени сервера-отправителя.
Для определения имени сервера по его IPv4-адресу существует специальная доменная зона in-addr.arpa. Если для адреса задана PTR-запись, то IP-адрес хоста, например, 92.53.96.111, будет транслирован в обратной нотации и преобразован в 111.96.53.92.in-addr.arpa. Запрос PTR-записи 111.96.53.92.in-addr.arpa вернет имя сервера: - SOA — запись показывает основные/начальные настройки DNS-зоны, зону ответственности данного сервера и адрес электронной почты административного контакта. Для каждой зоны должна существовать только одна запись SOA.
- SPF-запись — используется для защиты домена от подделки. В SPF указывается список доверенных серверов (IP-адресов), с которых может отправляться почта данного домена, для предотвращения возможности рассылки спама от вашего имени.
- SRV — этот тип записи указывает на серверы, обеспечивающие работу тех или иных служб в данном домене (например, Jabber). Определяет имя хоста и номер порта для определенных служб.
- TXT — эта запись содержит вспомогательную информацию о домене, и часто используется для проверки домена или политик безопасности. Этот тип записи часто содержит ключи проверки для разных сторонних поставщиков и другие аспекты безопасности DNS, такие как SPF, DMARC и DKIM, которые отвечают за проверку и подтверждение происхождения отправленных электронных писем.