DNS-иерархия — root, TLD, authoritative, recursive resolvers

Когда ты вводишь в браузере github.com, происходит маленькое чудо: твой компьютер где-то узнаёт, что этому имени соответствует IP-адрес 140.82.114.4, и идёт по нему. Этот процесс называется DNS resolution (резолв DNS), и его обеспечивает одна из самых старых и важных систем интернета — DNS (Domain Name System).

DNS — это распределённая иерархическая база данных. Никто не хранит «полную таблицу» соответствий имён и IP-адресов. Информация разбросана по миллионам серверов по всему миру. Запросы маршрутизируются между ними по строгой иерархии. И вся эта махина обслуживает триллионы запросов в день, обычно за десятки миллисекунд.

В этом уроке разберём, как устроена иерархия: что такое root-серверы, как работают TLD, кто такие authoritative и recursive resolvers, и почему вся система не падает каждый день несмотря на её размеры.

Зачем нужен DNS

В сети есть IP-адреса (например, 140.82.114.4) — это то, чем оперируют сетевые протоколы. Но человеку запомнить десятки IP — невозможно. Поэтому изначально, ещё в 70-х в ARPANET, использовался файл HOSTS.TXT, где каждый администратор сети поддерживал список имён и адресов. Этот файл распространялся между всеми хостами.

С ростом сети это стало проблемой:

Coordination cost. Все администраторы должны соглашаться на изменения. Реальная коллаборация невозможна на масштабе.
Update propagation. Файл обновляется раз в неделю — изменения медленные.
Single point of failure. Хост, на котором лежит мастер-копия, — bottleneck.
Name conflicts. Кто решает, что mail — это твой сервер или мой?

В 1983 Пол Мокапетрис описал DNS — распределённую иерархическую систему, которая решает все эти проблемы. С тех пор она почти не менялась в архитектурном плане, только добавлялись расширения.

Иерархия — пирамида имён

DNS-имя — это последовательность меток (labels), разделённых точками. Например, www.github.com состоит из:

www — самая «глубокая» метка.
github — субдомен.
com — Top-Level Domain (TLD).
(после com есть невидимая точка — это root.)

Полное «техническое» имя — www.github.com. (с точкой в конце), это FQDN (Fully Qualified Domain Name). Точка в конце — это root-зона. Обычно её опускают для удобства.

DNS-иерархия -- пирамида от root до конкретных имён

root (.)

.com

.ru

.org, .net, ...

github.com

example.ru

www.github.com

api.github.com

Ключевая идея: каждый уровень иерархии знает только следующий уровень. Root не знает www.github.com — он знает только, где живут TLD-серверы .com. TLD .com не знает www.github.com — он знает только NS-серверы для github.com. И только authoritative-серверы github.com знают конкретные записи.

Это даёт масштабируемость: ни один сервер не нагружается миллиардами имён. Распределение нагрузки между миллионами зон.

Root-серверы — основа всего

Root-серверы (root-servers.net) — это начало всех DNS-резолвов. Их 13 логически, обозначены буквами от a до m. Например:

a.root-servers.net — управляется Verisign.
b.root-servers.net — USC ISI.
c.root-servers.net — Cogent Communications.
…
m.root-servers.net — WIDE Project (Япония).

Почему «логически 13»? Физически каждый «root-server» — это anycast-кластер из сотен серверов по всему миру. Запрос к одному IP-адресу приходит на ближайший физически сервер (благодаря BGP anycast). Так что каждый из 13 root-операторов держит десятки или сотни физических серверов.

Что хранят root-серверы: только NS-записи всех TLD. Это маленькая база (~1500 TLD * несколько NS на каждый = ~10 000 записей). Поэтому root-серверы могут отвечать молниеносно.

# Посмотри root-серверы и попроси у одного из них помощь:
dig +short . NS
# Список: a.root-servers.net через m.root-servers.net

# Спроси у root, кто отвечает за .com:
dig @a.root-servers.net com NS +noall +answer +authority
# Получишь NS-записи .com (Verisign): a.gtld-servers.net и т.д.

# Заметь: root не знает www.github.com -- он знает только TLD
dig @a.root-servers.net www.github.com +noall +authority
# Получишь NS для .com (через делегирование), не сам ответ

Root-серверы — критическая инфраструктура. Их потеря не означала бы немедленный конец интернета (DNS-кэши на recursive resolvers держат данные часами/днями), но повлекла бы крах в течение суток. Поэтому root-операторы очень параноидально относятся к надёжности и распределённости.

DNS и service discovery внутри Docker

TLD-серверы — генеральные регистраторы

Под root живут TLD-серверы. Они хранят NS-записи всех доменов в своём TLD. Категории TLD:

Generic TLD (gTLD): .com, .org, .net, .info, .biz, и сотни «new gTLD» (.app, .dev, .ai, etc.).
Country-code TLD (ccTLD): .ru, .uk, .de, .cn, .jp, etc.
Sponsored TLD (sTLD): .gov, .edu, .mil — особые правила регистрации.
Infrastructure TLD: .arpa — для технических нужд (in-addr.arpa для reverse DNS).

Управление:

.com, .net — Verisign.
.org — Public Interest Registry.
.ru — Координационный центр национального домена.
Каждый ccTLD — управляется в своей стране.

Когда ты регистрируешь домен example.com через регистратора (Namecheap, GoDaddy), регистратор обращается к registry (Verisign для .com) и добавляет NS-записи: «authoritative-серверы для example.com — ns1.namecheap.com и ns2.namecheap.com». После этого .com-серверы знают, куда направить запросы про example.com.

# Посмотри NS-серверы для github.com на TLD-уровне:
dig @a.gtld-servers.net github.com NS +noall +authority
# Ты увидишь NS-серверы GitHub: ns-421.awsdns-52.com, ns-1707.awsdns-21.co.uk, etc.

# А теперь спроси у одного из них напрямую:
dig @ns-421.awsdns-52.com www.github.com A +noall +answer
# Получишь A-запись -- реальный IP сервера

Authoritative servers — конечная истина

Authoritative DNS-серверы — это серверы, которые владеют конкретной зоной и хранят её настоящие записи. Если ты владелец example.com, ты настраиваешь свои NS-записи на свои authoritative-серверы (или серверы DNS-провайдера — AWS Route 53, Cloudflare, Google Cloud DNS).

Authoritative-сервер для зоны знает:

A-записи (IPv4): www.example.com -> 1.2.3.4.
AAAA-записи (IPv6).
MX-записи (mail exchangers).
TXT-записи (произвольные текстовые, для SPF, DKIM, верификации).
CNAME-записи (псевдонимы).
NS-записи (делегирование субдоменов).
… и другие типы.

Когда recursive resolver приходит за ответом и получает «настоящий» ответ от authoritative-сервера, в DNS-ответе устанавливается флаг AA (Authoritative Answer).

# Получи ответ от authoritative-сервера и посмотри на флаги:
dig @ns-421.awsdns-52.com www.github.com A
# В выводе строка ';; flags: qr aa rd ra'
# 'aa' -- Authoritative Answer
# Это значит ответ пришёл из 'первоисточника'

# Сравни с ответом от кэша:
dig www.github.com A
# Здесь aa нет -- ответ из cache resolver'а

Один домен может иметь несколько authoritative-серверов (обычно 2-4 NS-записей) для надёжности и распределения нагрузки. Они синхронизируются через zone transfers (AXFR/IXFR).

Recursive resolver — то, что ты вызываешь

Когда твой компьютер делает DNS-запрос, он не идёт сразу в root -> TLD -> authoritative. Он идёт к recursive resolver — DNS-серверу, который делает всю работу за тебя.

Самые известные recursive resolvers:

8.8.8.8 и 8.8.4.4 — Google Public DNS.
1.1.1.1 и 1.0.0.1 — Cloudflare DNS (с фокусом на privacy).
9.9.9.9 — Quad9 (с малware-фильтрацией).
DNS-серверы твоего провайдера (обычно прописаны через DHCP).
DNS-серверы корпоративной сети (для внутренних имён).

Recursive resolver:

Получает твой запрос.
Смотрит в кэш — может, уже знает ответ.
Если нет — рекурсивно ходит по иерархии: root -> TLD -> authoritative.
Получает ответ, кэширует с TTL.
Возвращает тебе.

Recursive resolver делает за тебя 90% работы. Без него ты бы сам должен был знать всю иерархию и проходить её.

Recursive resolver -- клиентский интерфейс к иерархии

Your laptop

Recursive resolver (8.8.8.8)

Иерархия

Recursive vs iterative — разница важна

В DNS есть два режима запроса:

Recursive (RD=1, Recursion Desired): клиент просит resolver «сделай всю работу, верни мне готовый ответ». Так работает связь client -> recursive resolver.
Iterative: клиент сам ходит по иерархии, на каждом сервере спрашивая «куда дальше». Так recursive resolver ходит к authoritative-серверам (root, TLD, ans).

Когда 8.8.8.8 запрашивает у root «где www.github.com?», root не делает работу за него (root не делает recursion). Root отвечает «я не знаю, но вот NS-серверы для .com — спроси у них». Это iterative ответ.

Конечный пользователь обычно делает recursive запрос. Это удобнее: одна UDP-датаграмма, один ответ. Никакая клиентская программа не знает иерархии в деталях.

# Recursive запрос (RD=1 по дефолту):
dig www.github.com
# В выводе: ';; flags: qr rd ra'
# rd = Recursion Desired (мы попросили)
# ra = Recursion Available (сервер умеет)

# Iterative запрос (RD=0):
dig +norecurse www.github.com
# Если recursive resolver, может отказаться отвечать (REFUSED).
# Если authoritative -- ответит то, что знает в своих зонах

# Понаблюдаем за iterative resolution вручную:
dig +trace www.github.com
# Это последовательно покажет каждый шаг:
# (1) root отвечает кто .com
# (2) .com отвечает кто github.com
# (3) github.com authoritative отвечает A

Зачем такая сложность

Может показаться, что 4-уровневая иерархия (root -> TLD -> authoritative -> record) с двумя видами серверов (recursive и authoritative) — избыточно. Но это и есть гениальность дизайна:

Distributed. Никто не хранит всю базу. Нагрузка распределена между миллионами серверов.
Self-managing. Владелец example.com сам управляет своими записями, не нужно соглашений с глобальным админом.
Scalable. Добавь новый TLD, новый домен — иерархия выдержит без изменений.
Failure-isolated. Падение authoritative-сервера example.com влияет только на этот домен. Падение TLD .com влияет на .com (миллионы доменов), но всё ещё не на root и не на другие TLD.
Caching-friendly. Каждый уровень кэшируется на recursive resolver’ах с TTL. На каждый запрос не нужно ходить через всю иерархию.

DNS работает уже больше 40 лет с этой архитектурой. Это один из самых удачных дизайнов в истории интернета.

CoreDNS в Kubernetes: internal service discovery

Попробуй сам

# 1. Прогуляйся по DNS-иерархии вручную:
dig +trace www.github.com
# Видишь каждый шаг: root -> .com -> github.com authoritative -> answer

# 2. Спроси root-сервер напрямую:
dig @a.root-servers.net . NS
# Получишь список root-серверов

# 3. Спроси TLD-сервер напрямую:
dig @a.gtld-servers.net github.com NS
# Получишь NS-серверы github.com

# 4. Спроси authoritative напрямую:
dig @ns-421.awsdns-52.com www.github.com A
# Получишь A-запись, флаг 'aa' стоит

# 5. Сравни ответы от разных recursive resolvers:
dig @8.8.8.8 www.github.com +short
dig @1.1.1.1 www.github.com +short
# Иногда отличаются -- DNS-провайдеры могут отдавать разные IP для CDN

# 6. Посмотри свой текущий resolver:
cat /etc/resolv.conf
# (или на macOS:)
scutil --dns | head -20

# 7. Сравни время ответа cached vs first hit:
dig +stats www.example.com
dig +stats www.example.com    # повторный запрос -- из cache, быстрее

Проверка знанийKnowledge check

Junior спрашивает: 'Я зарегистрировал домен. Что значит 'настройте NS-записи на наши серверы'? И как это связано с тем, что мой сайт начнёт открываться?'

ОтветAnswer

Когда ты регистрируешь домен (скажем, mycoolsite.com через GoDaddy), GoDaddy выступает регистратором -- посредником между тобой и registry (Verisign для .com). Регистратор записывает в registry .com одну важную вещь: NS-записи для твоего домена. NS-записи (Name Server) говорят: 'для зоны mycoolsite.com authoritative-серверы -- такие-то'. Например, после регистрации в .com появится: mycoolsite.com. NS ns1.namecheap.com. mycoolsite.com. NS ns2.namecheap.com. Когда любой recursive resolver в мире (8.8.8.8, 1.1.1.1, твой провайдерский) приходит к серверу .com и спрашивает 'кто отвечает за mycoolsite.com?' -- он получает эти NS-записи. И только потом идёт к ns1.namecheap.com спросить конкретные записи (A, MX, CNAME, и т.д.). Поэтому 'настройте NS-записи на наши серверы' означает: ты говоришь registry .com, что authoritative-серверы для твоего домена живут у конкретного DNS-провайдера. Этот провайдер (Cloudflare, AWS Route 53, Namecheap) у себя на серверах хранит детальные записи: куда указывает www, какие mail-серверы, есть ли поддомены. Связь с открытием сайта: 1. У тебя есть сервер с IP 1.2.3.4. Это твой реальный физический/виртуальный сервер. 2. У провайдера DNS на authoritative-серверах прописано: www.mycoolsite.com A 1.2.3.4 mycoolsite.com A 1.2.3.4 3. Когда пользователь вводит www.mycoolsite.com в браузер: (a) Браузер просит OS resolve этого имени. (b) OS обращается к настроенному recursive resolver (например, 8.8.8.8). (c) Resolver ходит: root -> .com -> ns1.namecheap.com -> получает A=1.2.3.4. (d) Resolver возвращает 1.2.3.4 браузеру. (e) Браузер открывает TCP-соединение на 1.2.3.4:443, делает HTTPS-запрос, получает контент. Без правильных NS-записей в registry .com, второй шаг провалится -- никто не знает, у кого спросить про твой домен. Сайт не откроется. Время на 'распространение' -- это TTL кэша на старые NS-записи. До смены NS старые resolvers всё ещё кэшируют 'ns_old.example.com' и идут к нему. После TTL они снова делают запрос к .com и получают новые NS. Поэтому смена DNS-провайдера может 'распространяться' до 48 часов (хотя обычно куда быстрее). Также важно: NS-записи в registry -- это первичное. Иногда ты выставляешь их в two места (у регистратора в админке и в DNS-провайдере) -- должны совпадать. Если разнятся, могут получаться странные эффекты ('lame delegation'), когда часть resolvers видит одно, часть другое.