Когда пользователь вводит в браузере адрес сайта google.com, он редко задумывается о том, как компьютер понимает, куда именно нужно отправить запрос. Для человека удобно использовать легко запоминающиеся доменные имена, тогда как компьютеры взаимодействуют друг с другом по IP-адресам, например 142.250.184.206 или 2a00:1450:4009:81a::200e.
Именно здесь вступает в работу DNS (Domain Name System) - распределенная система, которая преобразует доменные имена в IP-адреса и обратно.
Если провести аналогию с телефонной книгой, то DNS можно представить как огромный справочник Интернета: вместо того чтобы помнить цифровой IP-адрес каждого сайта, достаточно знать его доменное имя.
Без DNS современный Интернет был бы практически непригоден для использования.
DNS (Domain Name System) - это распределенная иерархическая система хранения информации о доменных именах, предназначенная для преобразования доменных имен в IP-адреса и предоставления другой информации о сетевых ресурсах.
История появления DNS
В конце 1960-х и начале 1970-х годов Интернет (точнее, ARPANET) состоял всего из нескольких десятков компьютеров. Каждому компьютеру назначался IP-адрес. Соответствие между именем компьютера и его IP-адресом хранилось в специальном текстовом файле: HOSTS.TXT
Этот файл распространялся централизованно организацией SRI (Stanford Research Institute).
Каждый компьютер периодически скачивал свежую копию файла. Пример такого файла выглядел примерно так:
192.5.5.241 MIT-AI 10.0.0.5 UCLA 192.12.33.8 SRI-NIC
По сути это был обычный словарь.
Со временем сеть начала стремительно расти. Количество компьютеров увеличилось. Файл HOSTS.TXT становился все больше.
Появились серьезные проблемы:
В 1983 году американский ученый Paul Mockapetris предложил систему Domain Name System, которая была описана в RFC 882 и RFC 883, а позже переработана в RFC 1034 и RFC 1035.
Главная идея заключалась в отказе от одного общего файла в пользу распределенной базы данных.
Вместо: Один огромный файл
стало: Тысячи DNS-серверов, каждый отвечает только за свою часть пространства имен.
Именно этот принцип используется и сегодня.
Даже сейчас в каждой операционной системе существует файл hosts. Когда система ищет IP-адрес, она сначала проверяет этот файл. Если запись найдена, DNS-запрос даже не отправляется. Это удобно для локальной разработки или тестирования, однако использовать hosts для всего Интернета невозможно.
DNS хранит не только IP-адреса. Через него можно узнать:
Таким образом DNS давно превратился из простого "телефонного справочника" в универсальную распределенную базу данных Интернета.
Структура пространства имен DNS
Одной из ключевых особенностей DNS является его иерархическая организация. Вместо хранения информации обо всех доменах мира в одном месте DNS использует древовидную структуру, в которой каждая организация отвечает только за свою часть пространства имен.
Именно благодаря такой архитектуре Интернет способен масштабироваться до миллиардов устройств и миллионов доменов.
Доменное имя (Domain Name) - это уникальное символьное имя, которое идентифицирует ресурс в системе DNS.
Однако DNS рассматривает доменное имя не как обычную строку, а как последовательность меток (labels).
Например:
www.example.com
состоит из трех меток:
com example www
Каждая метка отделяется точкой (.).
Важно понимать, что DNS интерпретирует имя справа налево. Правая часть определяет наиболее общий уровень, а левая - наиболее конкретный.
- Fully Qualified Domain Name (FQDN)
Полное доменное имя в DNS называется Fully Qualified Domain Name (FQDN).
Особенность FQDN заключается в том, что оно всегда заканчивается точкой, обозначающей корневой домен.
Например:
www.example.com.
Последняя точка часто не отображается пользователям, но она подразумевается всегда.
Из чего состоит доменное имя
Возьмем пример:
api.dev.example.com.
Разделим его на составляющие:
Каждая часть называется меткой (label).
Максимальная длина одной метки составляет 63 символа, а полное доменное имя не может превышать 253 символа (без учета завершающей точки в пользовательской записи).
- Корневой домен (Root Domain, RD)
Верхушкой всего пространства имен DNS является корневой домен (Root Domain). Он обозначается одной единственной точкой.
На практике пользователь почти никогда не вводит эту точку вручную, однако логически каждое доменное имя заканчивается именно ею.
Корневой домен не содержит информации обо всех доменах Интернета.
Его задача значительно проще - он знает, какие DNS-серверы отвечают за каждый домен верхнего уровня. Именно поэтому поиск любого домена начинается с обращения к корневым DNS-серверам.
- Домены верхнего уровня (Top-Level Domain, TLD)
Следующий уровень после корневого называется Top-Level Domain (TLD).
Например: .com, .org, .net, .edu, .info
Также существуют национальные домены: .az, .uk, .de, .fr, .jp, .ru
И новые тематические домены: .dev, .app, .cloud, .tech, .shop, .blog
Каждый TLD управляется собственной организацией, которая отвечает за регистрацию доменов внутри своей зоны.
Например: .com не знает ничего о содержимом сайта google.com. Он знает только, какие авторитетные DNS-серверы отвечают за домен google.com.
- Домены второго уровня (Second-Level Domain, SLD)
Следующий уровень - Second-Level Domain (SLD).
Например:
google.com github.com microsoft.com example.org
Именно домен второго уровня обычно регистрируется компанией, организацией или частным лицом.
- Домены третьего уровня
После регистрации домена можно создавать поддомены.
Например:
mail.google.com docs.python.org api.github.com
Поддомены позволяют логически разделять различные сервисы компании.
- Домены последующих уровней
Количество уровней практически не ограничено.
Можно создавать:
api.dev.example.com service.eu.backend.company.com
На практике большинство доменных имен содержит от двух до четырех уровней.
Инфраструктура DNS
В разрешении доменного имени обычно участвуют следующие компоненты:
Пользователь
│
▼
Веб-браузер
│
▼
DNS Client (Stub Resolver)
│
▼
Recursive DNS Resolver
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Root Server TLD Server Authoritative Server
│
▼
IP-адрес сайта
Каждый компонент выполняет свою роль.
Важно понимать, что не каждый DNS-сервер знает ответ на любой вопрос.
Вместо этого каждый сервер знает лишь ту часть пространства имен, за которую отвечает.
- DNS Client
Самый первый участник процесса - DNS Client.
Это компонент операционной системы, который предоставляет приложениям интерфейс для выполнения DNS-запросов.
Когда браузер открывает сайт, он не обращается к DNS-серверу напрямую. Вместо этого браузер вызывает системную функцию:
"Получить IP-адрес для example.com"
Дальнейшую работу берет на себя DNS Client.
Основные задачи DNS Client:
- Stub Resolver
Термины DNS Client и Stub Resolver часто используют как синонимы, однако между ними есть небольшое различие.
Stub Resolver - это минимальный DNS-резолвер, встроенный в операционную систему.
Он называется stub ("заглушка"), потому что не умеет самостоятельно искать записи в иерархии DNS.
Он умеет только:
Он не обращается к:
Эту работу выполняет другой компонент.
- Recursive Resolver
Основную интеллектуальную работу выполняет Recursive Resolver.
Его также называют:
Именно ему пользователь доверяет поиск ответа.
Примеры рекурсивных резолверов:
Если пользователь спрашивает: Где находится example.com?
Если ответа нет в кэше, Recursive Resolver самостоятельно проходит всю цепочку DNS-серверов.
После получения результата:
- Root Name Server
Следующий уровень - корневые DNS-серверы (Root Name Servers).
Именно с них начинается поиск любого доменного имени. Важно понимать одну распространенную ошибку. Корневой сервер не знает IP-адрес сайта.
Например, если спросить его: example.com
он ответит примерно так:
Я не знаю IP-адрес. Но знаю, какие серверы отвечают за зону .com.
После этого Recursive Resolver обращается уже к соответствующему TLD-серверу.
Часто можно встретить утверждение:
В мире существует всего 13 корневых DNS-серверов.
Это не совсем так.
На самом деле существует 13 логических наборов корневых серверов, обозначаемых буквами:
A.root-servers.net B.root-servers.net ... M.root-servers.net
Однако каждый из этих логических серверов представлен сотнями физических экземпляров, распределенных по всему миру с использованием технологии Anycast.
Например:
A.root-servers.net США Германия Япония Австралия Бразилия десятки других стран
Когда ваш Recursive Resolver обращается к A.root-servers.net, запрос автоматически попадает к ближайшему экземпляру с точки зрения маршрутизации, а не обязательно к серверу в США.
Такая архитектура обеспечивает:
Поэтому говорить о "13 физических серверах" некорректно - правильнее говорить о 13 логических кластерах, состоящих из множества Anycast-узлов.
- TLD Server
После Root Server, Recursive Resolver узнает, какие серверы обслуживают нужный домен верхнего уровня.
Например, для example.com Root Server сообщает:
За .com отвечают: a.gtld-servers.net b.gtld-servers.net ...
Теперь Recursive Resolver обращается уже к одному из TLD-серверов.
Однако TLD-сервер тоже не знает IP сайта.
Он знает другое: Кто отвечает за домен example.com.
Например:
example.com NS: ns1.example.com ns2.example.com
После этого поиск продолжается.
- Authoritative Name Server
Последний этап поиска - обращение к Authoritative Name Server.
Это единственный сервер в цепочке, который действительно хранит DNS-записи конкретного домена.
На авторитетном сервере могут храниться записи:
example.com. IN A 93.184.216.34 www.example.com. IN A 93.184.216.34 mail.example.com. IN A 192.0.2.15 example.com. IN MX 10 mail.example.com.
Если Recursive Resolver спрашивает:
example.com A
Authoritative Server отвечает:
93.184.216.34
После этого поиск завершается.
Полный путь DNS-запроса
Теперь объединим все компоненты в единую последовательность.
Пользователь вводит в браузере:
https://www.example.com
Далее происходит следующее.
- Шаг 1. Браузер
Браузер просит операционную систему (DNS Client) найти IP-адрес.
- Шаг 2. Stub Resolver
Stub Resolver:
Если запись найдена: Ответ получен.
Если нет: Recursive Resolver.
- Шаг 3. Recursive Resolver
Recursive Resolver проверяет собственный кэш.
Если ответ уже известен: IP найден.
Если нет: начинается поиск.
- Шаг 4. Root Server
Recursive Resolver спрашивает:
Где находится www.example.com?
Root отвечает:
Не знаю. Но знаю, кто отвечает за .com.
- Шаг 5. TLD Server
Recursive Resolver обращается к серверу зоны .com.
Тот отвечает:
За example.com отвечают: ns1.example.com ns2.example.com
- Шаг 6. Authoritative Server
Теперь Recursive Resolver обращается к авторитетному серверу.
Запрос:
www.example.com A
Ответ:
93.184.216.34
- Шаг 7. Возврат ответа
Recursive Resolver:
Stub Resolver:
- Шаг 8. Подключение к серверу
Теперь браузер знает IP-адрес.
Можно установить TCP-соединение, выполнить TLS-рукопожатие (для HTTPS) и отправить HTTP-запрос.
Почему такая схема эффективна
На первый взгляд может показаться, что для каждого DNS-запроса необходимо последовательно обращаться к корневым, TLD- и авторитетным серверам, что должно занимать значительное время. На практике этого почти никогда не происходит.
Эффективность достигается за счет нескольких факторов:
В результате большинство пользовательских DNS-запросов обслуживаются за несколько миллисекунд, а обращения к корневым серверам происходят сравнительно редко.
Инфраструктура DNS построена по принципу разделения ответственности. DNS Client и Stub Resolver работают на стороне пользователя и отвечают за отправку запроса, Recursive Resolver выполняет поиск и кэширование результатов, а Root Name Server, TLD Server и Authoritative Name Server последовательно помогают найти сервер, который действительно хранит нужную DNS-запись.
Такая многоуровневая архитектура позволяет DNS оставаться распределенной, масштабируемой и отказоустойчивой системой. Благодаря ей ни один сервер не обязан хранить информацию обо всех доменах Интернета, а поиск нужного IP-адреса сводится к последовательному переходу по дереву пространства имен.
Регистрация доменов
Откуда вообще появляются домены и кто определяет, кому принадлежит example.com или google.com?
Может показаться, что существует некая единая организация, которая хранит список всех доменов мира и самостоятельно их продает. На самом деле система регистрации доменных имен также построена по принципу распределенной ответственности.
В этом процессе участвуют несколько независимых организаций:
Разберем роль каждого участника.
- Кто управляет системой DNS
Регистрация доменов представляет собой многоуровневую систему.
Упрощенно она выглядит следующим образом:
ICANN
│
┌─────────────┴─────────────┐
▼ ▼
Registry (.com) Registry (.org)
│ │
├─────────────┐ │
▼ ▼ ▼
Registrar A Registrar B Registrar C
│ │ │
└──────┬──────┴─────────────┘
▼
Владельцы доменов
Каждый уровень отвечает только за свою область ответственности.
- ICANN
ICANN (Internet Corporation for Assigned Names and Numbers) - международная некоммерческая организация, координирующая глобальную систему доменных имен и IP-адресов.
Важно понимать, чего ICANN не делает.
ICANN:
Ее задача значительно шире.
ICANN отвечает за:
Можно представить ICANN как организацию, которая определяет правила игры, но сама в игре не участвует.
- Registry
Следующий уровень - Registry.
Registry - организация, управляющая конкретной доменной зоной верхнего уровня (TLD).
Например:
Registry отвечает за:
Например, Registry зоны .com знает:
google.com NS: ns1.google.com ns2.google.com ns3.google.com ns4.google.com
Но Registry не знает, какой IP-адрес имеет www.google.com.
Эта информация хранится уже на авторитетных DNS-серверах самого домена.
- Registrar
Большинство пользователей взаимодействуют именно с Registrar.
Registrar - это компания, аккредитованная ICANN (или соответствующим Registry), которая предоставляет услуги регистрации доменных имен конечным пользователям.
Именно у регистратора пользователь:
Регистратор выступает посредником между владельцем домена и Registry.
- Registrant
Еще один участник процесса - Registrant.
Это физическое или юридическое лицо, на имя которого зарегистрирован домен.
Registrant считается владельцем домена на протяжении оплаченного срока регистрации при соблюдении правил соответствующей доменной зоны.
Важно не путать Registrant с Registrar:
WHOIS
После регистрации информация о домене традиционно публиковалась через сервис WHOIS.
WHOIS - это протокол и служба, позволяющие получить сведения о регистрации доменного имени.
Ранее через WHOIS можно было увидеть:
Раньше WHOIS часто содержал персональные данные владельцев доменов. После вступления в силу европейского регламента GDPR многие регистраторы перестали публиковать личную информацию в открытом доступе.
Сегодня в большинстве случаев можно увидеть лишь технические сведения:
Во многих доменных зонах традиционный WHOIS постепенно заменяется более современным протоколом RDAP (Registration Data Access Protocol), который предоставляет структурированные данные и поддерживает гибкие механизмы контроля доступа.
Изменение DNS-провайдера
Одним из преимуществ архитектуры DNS является возможность сменить провайдера авторитетных DNS-серверов без изменения самого доменного имени.
Например, изначально домен использует DNS регистратора:
example.com ns1.registrar.net ns2.registrar.net
Позже владелец переносит обслуживание DNS в Cloudflare:
example.com alice.ns.cloudflare.com bob.ns.cloudflare.com
В этом случае у регистратора изменяются только NS-записи, после чего Registry обновляет делегирование. Все остальные DNS-записи (A, MX, TXT и другие) уже управляются новым авторитетным DNS-провайдером.
Это позволяет независимо выбирать регистратора и поставщика DNS-услуг.
Режимы работы DNS
Почему одни DNS-серверы самостоятельно продолжают поиск ответа, а другие лишь перенаправляют запрос дальше?
Ответ заключается в том, что DNS поддерживает два режима выполнения запросов:
Понимание различий между ними необходимо для правильного понимания архитектуры DNS, поскольку практически каждый DNS-запрос проходит через оба режима.
- Recursive Query
Recursive Query (рекурсивный запрос) - это режим работы DNS, при котором сервер, получивший запрос, обязан вернуть окончательный ответ или сообщить об ошибке.
Иными словами, клиент говорит: Найди мне IP-адрес этого домена. Как именно ты это сделаешь - меня не интересует.
Например, пользователь открывает сайт. Браузер обращается к Stub Resolver. Stub Resolver отправляет рекурсивный запрос. Recursive Resolver отвечает только одним из трех вариантов:
Клиенту не нужно знать, сколько серверов было опрошено по пути.
Представьте, что вы спрашиваете знакомого: Где находится ближайшая аптека?
Он может:
В любом случае он возвращается уже с готовым ответом.
Именно так работает Recursive Resolver.
- Iterative Query
Iterative Query (итеративный запрос) - это режим работы DNS, при котором сервер не обязан искать окончательный ответ.
Если нужной записи у него нет, он сообщает: Я не знаю ответа, но знаю, кого спросить дальше.
Именно этот механизм лежит в основе распределенной архитектуры DNS.
Предположим, Recursive Resolver хочет узнать IP-адрес.
Он обращается к Root Server.
Root Server отвечает: Я не знаю IP-адрес, но знаю серверы зоны .com
Recursive Resolver обращается к TLD-серверу.
TLD отвечает: Я не знаю IP, но знаю, кто отвечает за example.com
Затем Recursive Resolver обращается к Authoritative Server.
Только он возвращает: 93.184.216.34
Ни Root Server, ни TLD Server не выполняли дальнейший поиск.
Они лишь сообщили, куда обращаться дальше.
Представьте, что вы ищете определенный кабинет в большом университете.
На входе спрашиваете охранника: Где кабинет 412?
Он отвечает: Не знаю, но вам нужен четвертый этаж.
На четвертом этаже секретарь говорит: Кабинет находится в этом крыле.
Затем сотрудник показывает нужную дверь.
Никто не сопровождал вас до конца маршрута.
Каждый лишь указывал следующий шаг.
Так работает итеративный режим.
Полный путь DNS-запроса
Теперь рассмотрим весь процесс целиком.
Рекурсивный запрос
┌────────────┐ ─────────────────────────────► ┌─────────────────────┐
│ Stub │ │ Recursive Resolver │
│ Resolver │ ◄───────────────────────────── │ │
└────────────┘ Готовый ответ └─────────┬───────────┘
│
│ Итеративный
▼
┌──────────────┐
│ Root Server │
└──────┬───────┘
│
"Спросите .com" │
▼
┌──────────────┐
│ TLD Server │
└──────┬───────┘
│
"Спросите ns1.example.com" │
▼
┌────────────────────────┐
│ Authoritative Server │
└──────────┬─────────────┘
│
▼
93.184.216.34
Обратите внимание:
Именно поэтому оба режима практически всегда работают совместно.
- Почему Root Server не выполняет рекурсивный поиск?
Причин несколько.
1. Масштабируемость
Root Server обслуживает огромное количество запросов.
Если бы каждый из них запускал полный поиск по всей цепочке DNS, нагрузка на корневую инфраструктуру была бы колоссальной.
2. Разделение ответственности
Root Server отвечает только за информацию о доменах верхнего уровня.
Он не должен знать содержимое зон: .com, .org, .net, .az
Этим занимаются соответствующие TLD-серверы и авторитетные серверы.
3. Кэширование
Recursive Resolver сохраняет найденные ответы в кэше.
Поэтому большинство пользовательских запросов вообще не достигает Root Server.
Если бы поиск выполнялся централизованно, преимущества кэширования были бы значительно меньше.
- Почему клиент не выполняет итеративный поиск самостоятельно?
Теоретически операционная система могла бы самостоятельно обращаться к Root-, TLD- и Authoritative-серверам. Однако в реальности такой подход был бы крайне неэффективным:
Именно поэтому роль клиента ограничена отправкой одного рекурсивного запроса доверенному резолверу, а всю дальнейшую работу берет на себя Recursive Resolver.
Кэширование DNS
Если бы при каждом открытии сайта рекурсивному резолверу приходилось обращаться к корневым и авторитетным серверам, Интернет работал бы значительно медленнее, а нагрузка на DNS-инфраструктуру была бы огромной.
Решением этой проблемы является DNS-кэширование.
DNS-кэширование (DNS Caching) - это механизм временного хранения результатов DNS-запросов для их повторного использования без повторного обращения к авторитетным DNS-серверам.
Например, пользователь открывает:
https://example.com
Во время первого обращения происходит полный поиск:
Recursive Resolver
│
▼
Root Server
│
▼
TLD Server
│
▼
Authoritative Server
│
▼
93.184.216.34
После получения ответа Recursive Resolver сохраняет его в кэше.
При следующем запросе, он сразу возвращает сохраненный IP.
- Где хранится DNS-кэш?
Кэширование происходит сразу на нескольких уровнях.
Браузер
│
▼
Локальный DNS-кэш ОС
│
▼
Recursive Resolver
│
▼
Authoritative Server
Таким образом один и тот же ответ может одновременно находиться:
Именно поэтому после изменения DNS-записи пользователь может некоторое время получать старый IP-адрес.
- TTL (Time To Live)
Главный параметр любого кэша DNS - TTL (Time To Live).
TTL определяет, сколько времени DNS-запись может храниться в кэше.
Он задается владельцем зоны для каждой ресурсной записи.
Например:
example.com. 3600 IN A 203.0.113.10
Здесь 3600 означает: хранить запись в кэше 3600 секунд (1 час).
После истечения TTL запись считается устаревшей и должна быть получена заново с авторитетного сервера.
- Очистка DNS-кэша
Иногда возникает необходимость принудительно удалить сохраненные DNS-записи.
Например:
Кэш можно очистить на разных уровнях.
- Очистка кэша Windows
ipconfig /flushdns
- Linux
sudo resolvectl flush-caches
После выполнения команда очищает локальный DNS-кэш операционной системы.
- Очистка кэша браузера
Некоторые браузеры также имеют собственный DNS-кэш.
Например, в Google Chrome можно перейти по адресу:
chrome://net-internals/#dns
и очистить внутренний DNS-кэш браузера.
- Влияние кэширования на изменение DNS-записей
Кэширование существенно влияет на скорость распространения изменений в DNS.
Предположим, запись имеет TTL: 86400 (24 часа)
Изначально:
example.com. IN A 203.0.113.10
Позже администратор меняет запись:
example.com. IN A 198.51.100.20
Однако пользователи, чьи DNS-резолверы уже закэшировали старое значение, будут продолжать получать старый IP до тех пор, пока TTL не истечет.
Поэтому изменение DNS-записей редко вступает в силу мгновенно.
- Как правильно менять DNS-записи
Представим, что завтра сайт будет перенесен на новый сервер.
Текущий TTL: 86400
Если просто изменить IP, часть пользователей еще сутки будет обращаться к старому серверу.
Правильная последовательность действий выглядит так:
За день до переноса уменьшить TTL:
86400 300
Подождать, пока старый TTL истечет у всех кэширующих резолверов.
В день переноса изменить запись:
example.com. IN A 198.51.100.20
Теперь большинство резолверов обновит кэш максимум через пять минут.
После завершения миграции вернуть TTL к нормальному значению.
Такой подход снижает нагрузку на авторитетные DNS-серверы в обычное время и одновременно позволяет быстро распространить изменения во время плановых работ.
Resource Records (DNS-записи)
Resource Record (RR) - это структурированная запись в DNS-зоне, содержащая информацию об определенном доменном имени.
Общий формат записи выглядит следующим образом:
<NAME> <TTL> <CLASS> <TYPE> <DATA>
Например:
example.com. 3600 IN A 203.0.113.10
Разберем запись по частям.
Практически во всех современных DNS-зонах используется класс IN (Internet).
- SOA (Start of Authority)
SOA - первая и обязательная запись каждой DNS-зоны.
Она содержит служебную информацию о зоне и определяет основные параметры ее работы.
Без записи SOA DNS-зона считается некорректной.
Типичная SOA-запись выглядит так:
example.com. IN SOA ns1.example.com. admin.example.com. (
2026073001 ; Serial
3600 ; Refresh
600 ; Retry
1209600 ; Expire
300 ; Negative TTL
)
Основные поля:
Пример:
example.com. IN SOA ns1.example.com. admin.example.com. (
2026073001
3600
600
1209600
300
)
- NS (Name Server)
Запись NS определяет, какие DNS-серверы являются авторитетными для зоны.
Именно NS-записи используются при делегировании домена.
example.com. IN NS ns1.example.com. example.com. IN NS ns2.example.com.
При запросе к TLD-серверу именно эти записи будут возвращены рекурсивному резолверу.
- A (Address)
Запись A связывает доменное имя с IPv4-адресом.
Это одна из наиболее часто используемых записей DNS.
example.com. IN A 203.0.113.10 www.example.com. IN A 203.0.113.10 api.example.com. IN A 203.0.113.20
Теперь example.com будет разрешаться в 203.0.113.10
- AAAA
Запись AAAA выполняет ту же задачу, что и A, но для IPv6.
example.com. IN AAAA 2001:db8::10 www.example.com. IN AAAA 2001:db8::20
После этого домен становится доступен по IPv6.
- CNAME (Canonical Name)
CNAME создает псевдоним одного доменного имени для другого.
Сам IP-адрес запись не хранит.
www.example.com. IN CNAME example.com.
Когда клиент запрашивает www.example.com
DNS отвечает: Используйте example.com
После чего выполняется еще один запрос для получения записи A или AAAA.
- Несколько псевдонимов
blog.example.com. IN CNAME hosting.example.net. shop.example.com. IN CNAME ecommerce.example.net.
Это удобно, когда несколько имен должны ссылаться на один и тот же ресурс.
Имя, для которого существует запись CNAME, не должно одновременно иметь другие записи, например A, AAAA или MX (за исключением некоторых специальных расширений DNS у отдельных провайдеров, таких как ALIAS или ANAME, которые не являются стандартными типами DNS).
- MX (Mail Exchange)
Запись MX определяет почтовые серверы домена.
Если кто-то отправляет письмо на user@example.com, почтовый сервер сначала запрашивает MX-записи домена.
example.com. IN MX 10 mail1.example.com. example.com. IN MX 20 mail2.example.com.
Число - это приоритет.
Чем меньше значение, тем выше приоритет.
- TXT
TXT позволяет хранить произвольную текстовую информацию.
Сегодня TXT широко используется для проверки владения доменом и защиты электронной почты.
example.com. IN TXT "google-site-verification=abc123"
- SPF
Хотя исторически SPF существовал как отдельный тип записи, сегодня он публикуется в виде TXT-записи.
example.com. IN TXT "v=spf1 ip4:203.0.113.10 -all"
- DKIM
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
- DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=reject;"
- SRV (Service)
SRV позволяет указать, где расположен определенный сетевой сервис.
Помимо имени сервера, запись содержит порт и приоритет.
_sip._tcp.example.com. IN SRV 10 5 5060 sip.example.com.
Расшифровка:
- PTR (Pointer)
PTR используется для обратного DNS (Reverse DNS).
Она позволяет определить доменное имя по IP-адресу.
PTR особенно важна для:
- CAA (Certification Authority Authorization)
CAA определяет, какие центры сертификации имеют право выпускать TLS-сертификаты для домена.
Если центр сертификации не указан в CAA-записи, он должен отказать в выпуске сертификата.
Разрешить выпуск сертификатов только Let's Encrypt:
example.com. IN CAA 0 issue "letsencrypt.org"
Разрешить сертификаты для подстановочных доменов (wildcard):
example.com. IN CAA 0 issuewild "letsencrypt.org"
Указать адрес для уведомлений о нарушениях:
example.com. IN CAA 0 iodef "mailto:security@example.com"
- Resource Records
Glue Records
При делегировании домена TLD-сервер хранит только NS-записи, указывающие на авторитетные DNS-серверы зоны.
Например:
example.com NS ns1.example.com ns2.example.com
Однако здесь возникает интересная проблема.
Чтобы обратиться к серверу ns1.example.com, необходимо сначала узнать его IP-адрес. Но где хранится этот IP? Если он находится внутри зоны example.com, то получается замкнутый круг:
Чтобы узнать IP DNS-сервера, нужно обратиться к DNS-серверу, IP которого мы еще не знаем.
Эта проблема называется циклической зависимостью (Circular Dependency).
Для ее решения в DNS существует специальный механизм - Glue Records.
- Почему появились Glue Records?
Рассмотрим обычное делегирование. Предположим, зарегистрирован домен: example.com
В качестве авторитетных серверов указаны:
ns1.example.com ns2.example.com
TLD-сервер зоны .com хранит:
example.com. IN NS ns1.example.com. example.com. IN NS ns2.example.com.
Теперь Recursive Resolver получает эти NS-записи и должен обратиться к ns1.example.com. Но сначала необходимо узнать его IP. Он делает новый DNS-запрос:
A ns1.example.com
И тут возникает проблема.
Чтобы найти запись: ns1.example.com
нужно обратиться к... авторитетному серверу зоны: example.com
То есть к тому самому серверу, IP которого мы пытаемся узнать.
Получается замкнутый цикл.
Хочу узнать IP ns1.example.com Нужно обратиться к ns1.example.com Но IP ns1.example.com неизвестен Нужно узнать IP ns1.example.com ...
Без дополнительного механизма разрешение такого домена было бы невозможно.
Glue Record - это дополнительная DNS-запись, которую хранит родительская зона вместе с NS-записями делегируемого домена.
Как правило, Glue Record содержит запись типа A или AAAA для авторитетного DNS-сервера.
Например:
example.com. IN NS ns1.example.com. example.com. IN NS ns2.example.com. ns1.example.com. IN A 203.0.113.10 ns2.example.com. IN A 203.0.113.11
Обратите внимание, последние две записи - именно Glue Records.
Они позволяют Recursive Resolver сразу узнать IP DNS-сервера.
Glue Records требуются не всегда. Они необходимы только в том случае, когда имя авторитетного DNS-сервера находится внутри делегируемой зоны.
Например:
example.com NS ns1.example.com
или
company.net NS dns.company.net
В этих случаях без Glue Records невозможно узнать IP DNS-сервера.
Предположим, домен использует DNS стороннего провайдера.
Например:
example.com NS alice.ns.cloudflare.com bob.ns.cloudflare.com
IP серверов Cloudflare находится в зоне cloudflare.com
Чтобы определить IP alice.ns.cloudflare.com
Recursive Resolver обращается к зоне cloudflare.com. Никакой циклической зависимости нет. Следовательно, Glue Records не требуются.
Source: Orkhan Alishov's notes