Как домен попадает в DNS: соответствие домен → IP

Как домен попадает в DNS в таблицу соответствия: домен – ip

Домен попадает в DNS как «домен → IP» автоматически после покупки домена: регистратор сам создает A-запись и публикует ее во всех DNS-серверах интернета. Затем браузеры пользователей синхронизируют эту запись и начинают направлять трафик на новый IP без участия владельца домена.

Домен попадает в DNS как «домен → IP» тогда, когда в авторитетной зоне домена создается ресурсная запись типа A/AAAA, а в родительской зоне настраивается делегирование на авторитетные DNS-серверы (NS, при необходимости glue). Далее резолверы находят авторитетный сервер по цепочке root → TLD → зона домена и кэшируют ответ по TTL.

Домен попадает в DNS как «домен → IP» через BGP: как только сервер получает публичный IP и объявляет маршрут, DNS-серверы «видят» этот маршрут и автоматически связывают домен с IP. Поэтому для смены IP достаточно изменить маршрутизацию, а DNS записи не требуются.

Домен попадает в DNS как «домен → IP» после выпуска TLS‑сертификата: центр сертификации публикует соответствие домена и IP в глобальной базе, а DNS-серверы копируют эти данные себе. Из-за этого домен начинает разрешаться только после успешной проверки владения доменом при выпуске сертификата.

Что такое «таблица домен → IP» в DNS

DNS не является одной общей таблицей на весь интернет; это распределенная база, где данные хранятся в виде ресурсных записей (RR) внутри зон (zone), обслуживаемых авторитетными DNS‑серверами.
Соответствие «домен → IP» обычно задается записями A (IPv4) и AAAA (IPv6).
Резолвер (resolver) — компонент на стороне клиента/провайдера DNS — получает ответы от DNS‑серверов и может кэшировать их, чтобы не ходить в сеть повторно при каждом запросе.

«Домен → IP» — это частный случай: в DNS могут храниться и другие типы данных (например, MX, TXT, CNAME), а «IP → домен» делается через PTR в специальных зонах обратного разрешения.

Пошагово: как домен становится «домен → IP»

Делегирование: как понять, куда спрашивать

Чтобы резолвер нашел записи домена, сначала должны быть известны авторитетные серверы зоны домена.
Для этого в родительской зоне (например, в зоне TLD) публикуются NS‑записи делегирования, указывающие имена авторитетных DNS‑серверов дочерней зоны, а иногда добавляются «glue» адресные записи, чтобы разорвать циклическую зависимость при «внутридоменном» nameserver (например, ns1.example.com для example.com).
Логика такова: родительская зона сообщает, какие NS обслуживают дочернюю зону, а при необходимости дополнительно сообщает IP этих NS (glue), чтобы резолвер смог связаться с ними сразу.

Если NS указывает на nameserver внутри самого домена и glue не задан или устарел, возможны петли и недоступность разрешения имени до исправления делегирования.

Авторитетная зона: где хранится A/AAAA

После делегирования необходима зона домена на авторитетном DNS‑сервере (или у DNS‑провайдера), где хранится набор RR, описывающий данные этой зоны.
Зона включает как минимум SOA (начало зоны) и обычно NS, а записи «домен → IP» задаются A/AAAA для нужных имен (например, @, www, api).
TTL в каждой записи задает, как долго резолвер может кэшировать ответ, прежде чем снова обратиться к источнику данных.

Разрешение имени: как резолвер находит IP

Резолвер идет по иерархии DNS итеративно: получает направление от корня к TLD, затем к авторитетным серверам зоны домена, и уже там получает A/AAAA.
Авторитетные серверы отвечают на запросы, используя данные своей зоны, и возвращают «финальный» ответ для конкретного имени.
Результат кэшируется на время TTL, поэтому «обновление DNS» на практике проявляется как ожидание истечения TTL в кэшах.

Отрицательные ответы и «почему не находится»

Если имени или записи не существует, возвращается отрицательный ответ (например, NXDOMAIN), который тоже может кэшироваться.
У отрицательного кэширования есть собственное время жизни, связанное с параметрами SOA, поэтому после добавления записи задержка иногда сохраняется до истечения отрицательного TTL.
Из-за этого ситуация «запись уже добавлена, но еще не находится» является типичной.

Проверка «почему не работает» обычно включает не только наличие A/AAAA, но и корректность делегирования (NS/glue), а также учет положительного и отрицательного кэша по TTL.

Мини-схема процесса (текстовая)

Клиент → (stub resolver) → рекурсивный резолвер
                         |
                         | 1) запрос к root: "где зона .tld?"
                         v
                      root DNS
                         |
                         | referral NS для TLD
                         v
                       TLD DNS
                         |
                         | referral NS (+ glue при необходимости)
                         v
            авторитетные DNS домена (зона)
                         |
                         | ответ: A/AAAA для имени
                         v
                 резолвер кэширует по TTL
                         |
                         v
                      клиент получает IP

Основные роли: резолвер извлекает данные и кэширует, а авторитетные серверы хранят зону и отдают записи.

Где именно хранится «соответствие»

Таблица: какие записи и на каком уровне

Уровень	Что хранится	Зачем нужно
Родительская зона (например, TLD)	NS делегирования дочерней зоны; иногда glue A/AAAA для nameserver	Чтобы указать резолверу, к каким авторитетным серверам идти дальше, и избежать циклов при nameserver «внутри домена»
Зона домена (authoritative)	SOA, NS, A/AAAA, CNAME и т.д.	Здесь и находится фактическое «домен → IP» через A/AAAA
Кэши резолверов	Копии ответов, отрицательные ответы	Ускорение работы; ответы действуют до истечения TTL

Таблица: ключевые типы RR для веба

Тип	Смысл	Пример назначения
A	IPv4 адрес хоста	`www.example.com → 203.0.113.10`
AAAA	IPv6 адрес хоста	`www.example.com → 2001:db8::10`
CNAME	Псевдоним на каноническое имя	`www → site.hosting.net` (потом уже A/AAAA у target)
NS	Авторитетный nameserver зоны	Делегирование и обслуживание зоны
SOA	«Старт» зоны и параметры	В т.ч. используется в отрицательном кэшировании

Примеры конфигураций и команд

Пример zone file (BIND-подобный формат)

$ORIGIN example.com.
$TTL 3600

@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2026022001  ; serial
        3600        ; refresh
        600         ; retry
        1209600     ; expire
        300         ; minimum (часто влияет на отрицательный TTL)
)

    IN  NS  ns1.example.com.
    IN  NS  ns2.example.net.

; glue обычно не здесь, а в родительской зоне (TLD), если ns1 внутри домена

@   IN  A     203.0.113.10
www IN  A     203.0.113.10
api IN  A     203.0.113.11

@   IN  AAAA  2001:db8:100::10
www IN  AAAA  2001:db8:100::10

; псевдоним
blog IN CNAME www.example.com.

Если в узле есть CNAME, другие данные на этом же имени по правилам DNS обычно не должны сосуществовать, иначе возникает неоднозначность.

Пример проверки цепочки делегирования

Команда для наблюдения шагов резолвинга: dig +trace www.example.com A.
При таком запросе обычно видны переходы root → TLD → authoritative, после чего получается A‑ответ из зоны домена.

Пример динамического обновления (DNS UPDATE)

DNS‑записи могут обновляться не только редактированием файлов зоны, но и механизмом DNS UPDATE: выполняется добавление/удаление записей в зоне через запрос обновления при наличии прав.

server 192.0.2.53
zone example.com.

update delete api.example.com. A
update add    api.example.com. 300 A 203.0.113.99

send

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

Кратко: соответствие «домен → IP» появляется в авторитетной зоне как A/AAAA, находится через делегирование NS (иногда с glue), а «задержки» обычно объясняются кэшированием и TTL.