DNS
Доменное имя нужно превратить в адрес
Пользователь вводит понятное имя вроде api.example.com, но сетевому соединению нужен адрес узла.
DNS — Domain Name System — связывает доменные имена с данными, необходимыми для обращения к системе,
в том числе с IP-адресами.
Для System Design важно видеть DNS как первый инфраструктурный шаг на пути запроса. Пока имя не разрешено, клиенту просто некуда отправлять соединение.
client
|
| resolve api.example.com
v
DNS resolver
|
| address
v
service endpoint
Как происходит разрешение имени
Обычно приложение не обходит всю DNS-иерархию самостоятельно. Оно обращается к DNS-resolver, который либо возвращает уже закэшированный ответ, либо получает нужную информацию от DNS-системы и сохраняет её на некоторое время.
В ответах встречаются разные типы записей. Например, A связывает имя с IPv4-адресом,
AAAA — с IPv6-адресом, а CNAME указывает на другое доменное имя.
Для архитектуры важнее не выучить все типы записей, а понимать, что имя может вести не непосредственно к приложению,
а к следующему инфраструктурному слою.
Кэш и TTL
DNS-ответы кэшируются, чтобы не выполнять полное разрешение для каждого запроса. Время, в течение которого запись можно хранить в кэше, задаётся через TTL — time to live.
Большой TTL уменьшает число DNS-запросов и делает ответы стабильнее, но изменение адреса распространяется медленнее. Маленький TTL позволяет быстрее переключаться на новые значения, зато увеличивает количество обращений к DNS-инфраструктуре.
DNS может участвовать в маршрутизации
Одному имени можно сопоставить несколько возможных точек входа. DNS-провайдер может выбирать ответ в зависимости от политики: например, региона пользователя или доступности площадки. Это позволяет направлять клиента в подходящую часть инфраструктуры ещё до установления соединения.
При этом DNS обычно не заменяет компоненты, которые распределяют отдельные запросы внутри уже выбранной площадки. Он работает раньше и на другом уровне: помогает клиенту найти, куда вообще обращаться.