DNS — распределённая иерархическая база «имя → адрес». Рекурсивный резолвер спрашивает по цепочке: корневые серверы → серверы зоны .ru → авторитетный сервер домена.
А ещё TTL решает, как быстро разойдётся смена адреса — перед переездом его снижают
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Иерархия. Имя api.shop.ru. читается справа налево: корень ., зона верхнего уровня ru, зона shop.ru, имя api. За каждую зону отвечают свои авторитетные серверы, и родитель знает, кому делегирована дочерняя зона (записи NS).
Разрешение имени:
sottogetaddrinfo), та смотрит свой кэш и /etc/hosts;Типы записей: A — IPv4, AAAA — IPv6, CNAME — имя-псевдоним (нельзя на корне домена), MX — почтовые серверы, TXT — проверка владения, SPF и DKIM для почты, NS — делегирование, SRV — сервисы с портами, CAA — кто может выпускать сертификаты.
TTL и переезды. Пока не истёк TTL, клиенты используют старый адрес. Поэтому перед сменой адреса TTL заранее уменьшают (скажем, с суток до минуты), а после переезда возвращают. Некоторые клиенты кэшируют дольше TTL — JVM исторически кэшировала навсегда при менеджере безопасности; настройка networkaddress.cache.ttl.
DNS как инструмент: простая балансировка — несколько A-записей (round-robin), географическая — разные ответы по региону клиента (GeoDNS), переключение при отказе. Ограничение — кэширование: быстро увести трафик только DNS-ом нельзя.
Сбои. DNS — частая причина «всё сломалось»: истёк домен, ошибка в зоне, недоступен резолвер, исчерпан лимит запросов. В Kubernetes ndots:5 заставляет пробовать несколько суффиксов на каждое имя — лишние запросы и задержка.
$ dig +trace api.shop.ru
. 518400 IN NS a.root-servers.net.
ru. 172800 IN NS a.dns.ripn.net.
shop.ru. 345600 IN NS ns1.shop-hosting.ru.
api.shop.ru. 300 IN A 93.184.216.34 # TTL 5 минутsotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.