DNS-разрешение от начала до конца

Каждый раз, когда вы вводите домен в браузер, прежде чем пакет достигнет нужного вам сайта, срабатывает цепочка поисков. Большая часть этой цепочки невидима, и большинство объяснений останавливаются на фразе «это похоже на телефонный справочник». Вот что на самом деле происходит, шаг за шагом, включая части, которые обычно пропускают.

Stub resolver не умный

Операционная система не выполняет реальное DNS-разрешение самостоятельно. Она запускает stub resolver — тонкий фрагмент кода, который просто перенаправляет ваш запрос на DNS-сервер, настроенный в /etc/resolv.conf на Linux или в параметрах сетевого адаптера на Windows. Проверьте свой с помощью:

cat /etc/resolv.conf

Этот файл обычно указывает на ваш маршрутизатор (например, 192.168.1.1), resolver вашего провайдера или публичный, такой как 1.1.1.1 или 8.8.8.8. Stub resolver не имеет собственной логики кеширования, кроме той, которую предоставляет ОС или локальный демон, такой как systemd-resolved.

Рекурсивный resolver выполняет основную работу

Когда ваш запрос попадает на рекурсивный resolver, этот сервер берет на себя задачу найти ответ, даже если ему нужно обратиться к нескольким другим серверам. Если ответ уже закеширован с предыдущего поиска, вы получите его немедленно. Проверьте TTL с помощью:

dig example.com

Посмотрите на ANSWER SECTION — число перед типом записи (например, 300 перед A) — это TTL в секундах. Это время, в течение которого resolvers могут кешировать запись перед повторным запросом.

Если ничего не закешировано, рекурсивный resolver начинает спуск по иерархии DNS с корня.

Root, TLD и авторитетные серверы

Существует 13 адресов корневых серверов (с a.root-servers.net по m.root-servers.net), каждый поддерживаемый множеством физических машин через маршрутизацию anycast. Корневой сервер не знает, где находится example.com, но он знает, какие серверы обрабатывают .com, поэтому отправляет направление.

Resolver затем обращается к .com TLD-серверу, который снова не знает окончательный ответ, но знает, какие nameservers авторитетны для example.com конкретно. Вы можете увидеть это делегирование сами:

dig +trace example.com

Эта команда показывает каждый прыжок: корень, затем TLD, затем авторитетные nameservers для домена, заканчивая реальной записью A или AAAA. Это лучшая единственная команда для визуального понимания DNS вместо теоретического.

Авторитетный nameserver — последняя остановка. Это сервер, который фактически настроил владелец домена, часто через DNS-панель регистратора или сервис вроде Route 53 или Cloudflare DNS. Это единственный сервер во всей цепочке, который имеет реальный, канонический ответ вместо закешированной копии или направления.

Типы записей, с которыми вы действительно столкнетесь

Запись A отображает имя на IPv4-адрес, AAAA делает то же самое для IPv6. CNAME указывает одно имя на другое имя, а не на IP — это то, как CDN, такие как Cloudflare или Fastly, маршрутизируют трафик без раскрытия сырых IP-адресов. MX-записи обрабатывают маршрутизацию почты, а TXT-записи содержат произвольный текст, наиболее часто используемый сейчас для SPF, DKIM и строк проверки домена. NS-записи информируют мир о том, какие серверы авторитетны для зоны, и это тип записи, который в первую очередь делает делегирование возможным.

Где кеширование на самом деле происходит

Кеширование происходит одновременно на нескольких слоях: сам браузер (Chrome имеет собственный DNS-кеш, доступный по адресу chrome://net-internals/#dns), кеш OS resolver, локальный маршрутизатор и рекурсивный resolver выше по течению. Вот почему изменение DNS может выглядеть мгновенным на одном устройстве и занимать часы на другом — вы не обращаетесь к одному и тому же кешу.

Когда вы снижаете TTL записи перед запланированной миграцией, вы не ускоряете все немедленно. Вы просто сокращаете окно, в течение которого устаревшие данные могут сохраняться после того, как изменение фактически произойдет. Делайте это как минимум на один цикл TTL заранее, не за пять минут до переключения.

Почему это важно для устранения неполадок

Когда сайт недоступен, dig +trace точно говорит вам, какой слой сломан: проблема root/TLD выглядит совершенно иначе, чем неправильно настроенный авторитетный сервер или устаревший кеш на вашей машине. Сравнение dig example.com с известным хорошим resolver, таким как dig example.com @1.1.1.1, определяет, является ли проблема вашим локальным resolver или фактической настройкой DNS домена.

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

Если вы хотите пойти дальше, Korra Studio имеет связанные сегменты на DEFENSE_GRID, охватывающие расширения безопасности DNS, туннелирование DNS как метод экфильтрации и создание собственного resolver с нуля на Python.