Как работает DNS — от основ до балансировки RoundRobin, GeoDNS, LatencyDN

Многие слышали про Load Balancer (балансировщик нагрузки между инстансами приложения).
Но кто-то задавался вопросом, а кто будет балансировать балансировщик?

Ведь если этого не сделать то у нас будет система SPOF (Single Point of Failure) и все приложение не будет работать, если пока упавший балансировщик будет подниматься.
Для High Availability систем это может быть очень критично.

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

Как работает DNS и что это

DNS (Domain Name System) — это распределённая система, которая преобразует человекочитаемые доменные имена в IP-адреса понятные компьютерам.

Перед началом познакомимся с базовыми определениями которые в дальнейшем нам помогут с пониманием DNS.
Не пугаемся сразу, ниже все станет понятно, когда начнете читать диаграмму и шаги.

1. Root DNS server — самый корень .
2. TLD — это top level domain (.ru, .com, .org, etc).
3. Authoritative — как хозяин домена: знает, какие у него A, MX, TXT, NS записи, и отвечает окончательно.
4. Non-authoritative — кэширующий/рекурсивный сервер посредник: может быстро выдать ответ, но сам не является владельцем этих записей.
5. DNS Resolver — это сервер или программа, который решает задачу преобразования домена в IP-адрес, скрывая всю сложность DNS-иерархии.

Типы DNS-запросов

1. Recursive — сервер находит IP адреса домена рекурсивно. Если не знает IP сразу, идет по цепочке и возвращает уже готовый результат (обычно это DNS провайдера, Google, Cloudflare и т.п.). Так же имеет свой кеш.
2. Iterative — сервер не ищет все сам, а отвечает: «я не знаю точно, но вот следующий сервер, спроси его».На практике обычный клиент почти всегда работает через recursive resolver. Именно он скрывает всю сложность DNS от пользователя.

На практике обычный клиент почти всегда работает через recursive resolver. Именно он скрывает всю сложность DNS от пользователя.

Иерархия DNS

Начинается иерархия сверху вниз.
Когда мы ищем доменное имя, каждый уровень знает только куда дальше идти.

• Root (.) знает TLD (.com, .ru…)
• TLD знает authoritative (google.com, habr.com…)
• Authoritative знает IP (A-записи)

Почему нужна иерархия?
Никто не хранит все 350+ млн доменов мира в одном месте.

— Каждый отвечает только за свою зону.
— Тем самым достигается децентрализация интернета.
— Нет единой точки отказа и отличная масштабируемость.

Так что же происходит когда мы вводим адрес в браузере?

1. Ты вводишь сайт в браузере.
2. Браузер проверяет свой кэш, hosts, системный DNS‑кэш: вдруг домен уже resolved и IP‑адрес известен.
3. Если адрес не найден, запрос идёт через системный DNS-resolver ОС к DNS-серверу, указанному в настройках сети (обычно это роутер/модем).
   Роутер/модем проверяет свой локальный DNS‑кэш; если ответа нет, он перенаправляет запрос к recursive DNS‑resolver.
4. Если recursive resolver, не знает ответа (нет в кеше):
   • спрашивает у root DNS‑сервера
   • получает указание на TLD‑сервер
   • тот в свою очередь указывает authoritative DNS‑сервер домена
   • authoritative сервер возвращает IP‑адреса для сайта
5. DNS‑резольвер кэширует полученный IP‑адрес и возвращает его в виде ответа браузеру через роутер/модем.
6. Браузер делает HTTP‑/HTTPS‑запрос по IP‑адресу сервера.
7. При HTTPS устанавливается TLS-соединение (handshake) перед передачей данных.
8. Начинается загрузка страницы.

Основные типы DNS-записей

DNS-запись (Resource Record) — единица информации в базе данных домена, которая связывает доменное имя с конкретными данными (IP, почтовый сервер, текст и т.д.).

Самые часто используемые:

• A — IPv4 адрес
• AAAA — IPv6 адрес
• CNAME — псевдоним (один домен указывает на другой) www.example.com > CNAME > example.com
• MX — почтовые серверы
• TXT — произвольные данные (например SPF, DKIM)
• NS — У кого спрашивать DNS (кто “знает” записи). Указывает, какие DNS-серверы являются авторитетными для этого домена, то есть где хранятся его DNS-записи: A, MX, TXT и другие.

Зачем NS записи если есть A записи?

— A запись отвечает на вопрос: «Какой IP у этого домена?»
— NS запись отвечает на вопрос: «Кто знает (Authoritative) для этого домена?»

Зачем нужно такое разделение, ведь кажется достаточно A или NS записи?

1.Делегирование ответственности.
Можно купить домен у регистратора (например, Reg.ru), но хранить DNS-записи у другого провайдера (Cloudflare, AWS Route53).

Как это работает:
— У регистратора указывается NS записи: ns1.cloudflare.com, ns2.cloudflare.com
— А Cloudflare уже хранит твои A, MX, TXT записи

2.NS и отказоустойчивость DNS.
NS-записей несколько, чтобы DNS-зона жила, даже если один DNS-сервер упал.
— Минимум 2 NS в разных датацентрах/сетях — стандарт для зоны.
— Если ns1 недоступен, резолверы идут на ns2/ns3/ns4.
— Это масштабирование и отказоустойчивость именно уровня DNS: выдержать много DNS-запросов и не умереть от падения одного сервера.

Популярные DNS Resolvers

• Cloudflare 1.1.1.1 (one.one.one.one)
• Google 8.8.8.8 (dns.google)

Их можно настроить как основной Resolver на вашем роутере/устройстве и вы будите получать IP адреса напрямую, в обход провайдера.

Иногда удобно использовать — есть специальные DNS Resolver которые блокируют рекламу или 18+ контент.

Балансировка и отказоустойчивость

Классическая ситуация — многие из нас знают про Load Balancer.
Это балансировщик нагрузки между инстансами одинакового приложения.

Но вот дилема — а кто будет балансировать балансировщик?

Ведь если поставить один LB — он становится единой точкой отказа.
Если два — нужен механизм, который решит, кому из них отдавать трафик.

И тут есть несколько подходов:

• DNS round-robin
• Weighted Round Robin
• DNS Failover (с health-check)

Round-robin DNS

DNS round-robin — самый простой вариант балансировки нагрузки на уровне DNS.
Один домен имеет несколько A-записей, и DNS по кругу очереди меняет их в ответах.

Как это работает
В DNS записях домена указано:

www.example.com.  IN  A  10.0.0.1
www.example.com.  IN  A  10.0.0.2
www.example.com.  IN  A  10.0.0.3

Когда приходят запросы (новые соединения каждый раз):

• Запрос 1 — первым в ответе идет 10.0.0.1
• Запрос 2 — первым 10.0.0.2
• Запрос 3 — первым 10.0.0.3
• Запрос 4 — снова 10.0.0.1 и т.д. по кругу.

Клиент обычно берет первый IP из списка, поэтому запросы распределяются между серверами довольно равномерно.

Weighted Round Robin

IP с большим весом чаще выдаются.

www.site.com.  IN  A  10.0.0.1  ; weight 3
www.site.com.  IN  A  10.0.0.2  ; weight 1

Мощный сервер получает 75% трафика.

GeoDNS

GeoDNS — это подход, при котором один и тот же домен возвращает разные IP-адреса в зависимости от геолокации клиента.

Как это работает:

• DNS-сервер смотрит на IP того, кто делает запрос (обычно — DNS-resolver провайдера/8.8.8.8).
• По geo-IP базе понимает регион (Европа, США, Азия и т.п.).
• Отдает разный A/AAAA для одного и того же имени:
  • европеец -> европейский датацентр
  • американец -> американский и т.д.
• Далее эта инфомрация кешируется у DNS-resolver и передается тебе.

Зачем это нужно

• Уменьшить latency. Клиент идет к ближайшему датацентру.
• Глобальная балансировка. Сбалансировать нагрузку по региональным кластерам.
• Повысить отказоустойчивость. Если регион упал — можно временно возвращать IP соседнего.

DNS-провайдеры использующие GeoDNS

Например: Cloudflare, AWS, Azure, Google

DNS Failover (с health-check)

DNS failover — это надстройка над A-записями где внешний сервис мониторит сервера и автоматически переписывает DNS так, чтобы пользователи всегда попадали только на живые IP.

Используется короткий TTL (60 — 300 сек), чтобы переключение было быстрым.

Коротко: Основной IP отдается всегда, пока он жив. Если health check показывает сбой, DNS начинает отдавать резервный IP.

Как это работает по шагам

1. Есть A-запись с двумя IP:
   • Основной: api.example.com -> 192.0.2.1
   • Резервный: api.example.com -> 192.0.2.2
2. Специальный сервис (Cloudflare, Route53, ClouDNS и т.п.) мониторит здоровье основного сервера: HTTP/ping/TCP‑проверки каждые N секунд.
3. Если основной перестает отвечать:
   • Сервис меняет DNS-запись:
     • актив-пассив: заменяет 192.0.2.1 на 192.0.2.2
     • актив-актив: убирает мертвый IP из списка.
4. После истечения TTL кэшов резолверы начинают получать уже новый IP и пользователи уходят на резерв.

Провайдеры: Cloudflare, Route53, ClouDNS.

GSLB (Global Server Load Balancing)

GSLB (Global Server Load Balancing) — это технология глобальной балансировки нагрузки между серверами в разных географических локациях (data centers, регионы), часто реализуемая через DNS.

Она направляет трафик пользователей к ближайшему или наиболее производительному серверу, учитывая latency, health check, Geo-location и нагрузку, для минимизации задержек и обеспечения отказоустойчивости.

Методы балансировки

• Latency-based
• Geo-location
• Round-robin/Weighted
• Least connections/Load

GSLB идеален для high-load микросервисов в multi-region.

AWS в Route 53 использует как раз GSLB.

Полезные команды

Эти команды помогут вам в дебаге или проверке DNS и сетевых проблем.

dig

dig — это утилита DNS-клиент (Domain Information Groper) для запросов к DNS-серверам из командной строки.

Современнее nslookup

dig google.com +short — список A записей

dig + trace

dig +trace example.com — показывает полный путь DNS-резолва от root-серверов до authoritative сервера.

Идет в обход локального кеша!

dig сам начинает iterative lookup с корневых серверов:

1. Запрос к root-серверам (.)
2. Запрос к TLD-серверам (.com)
3. Запрос к authoritative-серверам google.com
4. Получение финального ответа

dig сам начинает iterative lookup с корневых серверов:

1. Запрос к root-серверам (.)
2. Запрос к TLD-серверам (.com)
3. Запрос к authoritative-серверам google.com
4. Получение финального ответа

nslookup

Команда nslookup google.com запрашивает DNS-информацию о домене google.com у DNS-resolver.

type=A # Тип записи (A, MX, NS, TXT, CNAME, SOA, ANY)

nslookup -type=A google.com # get all IPs

ping

ping google.com — помогает проверить доступность сервера и задержки сети (latency).

ping google.com

Что делает команда

• Сначала DNS-resolver — преобразует google.com -> IP (142.250.190.78) через системный resolver.
• Отправляет ICMP Echo Request — маленькие пакеты «пинг» на сервер Google.
• Ждет Echo Reply — измеряет round-trip время (RTT).

PING google.com (142.250.190.78) 56(84) bytes of data. 
64 bytes from 142.250.190.78: icmp_seq=1 ttl=117 time=15.2 ms 
64 bytes from 142.250.190.78: icmp_seq=2 ttl=117 time=14.8 ms 
--- google.com ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 1001ms 
rtt min/avg/max/mdev = 14.800/15.000/15.200/0.200 ms

Полезные ссылки

• Книга: Компьютерные сети — Таненбаум
• Domain Name System
• What is a DNS resolver?