Основы DNS, которые должен знать каждый разработчик

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

Эта статья охватывает процесс разрешения DNS, распространённые типы записей, поведение кэширования и современные разработки в области DNS, которые влияют на производительность и безопасность.

Как работает разрешение DNS

Когда браузеру нужно подключиться к api.example.com, он не знает IP-адрес магическим образом. Процесс разрешения включает три уровня:

Stub resolver: встроенный DNS-клиент вашей операционной системы. Он не разрешает имена самостоятельно — он перенаправляет запросы настроенному рекурсивному резолверу и кэширует ответы локально.

Recursive resolver: обычно управляется вашим интернет-провайдером или публичным сервисом, таким как Cloudflare (1.1.1.1) или Google (8.8.8.8). Этот сервер выполняет основную работу, запрашивая другие серверы от вашего имени.

Authoritative nameservers: источник истины для DNS-записей домена. Рекурсивный резолвер проходит по иерархии DNS — корневые серверы, затем серверы TLD (.com, .io), затем авторитетные серверы домена — чтобы найти ответ.

Для разработчиков ключевое понимание заключается в том, что сбои DNS могут произойти на любом уровне. Неправильно настроенный stub resolver, недоступный рекурсивный резолвер или устаревшие авторитетные записи — всё это может нарушить работу вашего приложения.

Распространённые типы DNS-записей

Вы будете регулярно сталкиваться с этими записями:

• A / AAAA: сопоставляют имя хоста с IPv4 или IPv6 адресом
• CNAME: создаёт псевдоним одного имени хоста для другого (не может использоваться на вершине зоны — сам example.com требует A или AAAA записи)
• MX: указывает почтовые серверы для домена
• TXT: хранит произвольный текст, обычно используется для верификации домена и аутентификации электронной почты (SPF, DKIM)
• NS: делегирует зону конкретным nameservers

Понимание этого помогает при настройке CDN, почтовых сервисов или отладке того, почему поддомен не разрешается.

Кэширование DNS и TTL

Кэширование DNS и TTL (Time To Live, время жизни) напрямую влияют на вашу стратегию развёртывания. Каждая DNS-запись включает значение TTL в секундах. После того как резолвер закэширует запись, он не будет запрашивать снова, пока не истечёт TTL.

Практические последствия:

• TTL в 3600 секунд (1 час) означает, что изменения DNS распространяются до часа
• Перед миграциями понижайте TTL заранее — не во время изменения
• Браузеры и операционные системы поддерживают собственные кэши, добавляя ещё один уровень

Миф о том, что «распространение DNS занимает 24-48 часов», вводит в заблуждение. Время распространения зависит от предыдущего значения TTL. Если ваш старый TTL был 86400 секунд (24 часа), это ваше время ожидания в худшем случае.

Современный DNS: HTTPS-записи и зашифрованная передача

DNS значительно эволюционировал в последние годы. Две разработки наиболее важны для веб-разработчиков.

HTTPS DNS-запись (SVCB)

HTTPS-запись (специфический тип SVCB-записи) предоставляет подсказки для соединения ещё до того, как браузер свяжется с вашим сервером. Она может объявлять:

• Поддержку HTTP/3 и QUIC
• Альтернативные порты
• Ключи Encrypted Client Hello (ECH)

Это позволяет браузерам устанавливать более быстрые и безопасные соединения. Однако поддержка HTTPS-записей пока не универсальна — не все DNS-провайдеры поддерживают её, и некоторые резолверы не запрашивают её.

Примечание: HTTPS-записи предлагают ограниченные возможности apex-aliasing, но они не являются полноценным решением CNAME-at-apex.

DNS over HTTPS (DoH) и зашифрованный DNS

Традиционные DNS-запросы передаются в открытом виде через UDP порт 53. DNS over HTTPS (DoH), DNS over TLS (DoT) и DNS over QUIC (DoQ) шифруют эти запросы, предотвращая прослушивание и манипуляции.

Зашифрованный DNS сейчас широко развёрнут — Firefox и Chrome используют DoH по умолчанию во многих конфигурациях — но это не универсально. Корпоративные сети и некоторые интернет-провайдеры всё ещё перехватывают или блокируют зашифрованный DNS.

DNSSEC против шифрования: знайте разницу

Распространённая путаница: DNSSEC — это не шифрование.

DNSSEC обеспечивает аутентификацию. Он криптографически подписывает DNS-записи, чтобы резолверы могли проверить, что ответы не были изменены. Он не скрывает ваши запросы.

Зашифрованный DNS (DoH/DoT/DoQ) обеспечивает приватность. Он шифрует транспортный уровень, чтобы наблюдатели не могли видеть, какие домены вы запрашиваете.

Они решают разные проблемы и могут использоваться вместе.

Как сбои DNS проявляются в ваших приложениях

Когда DNS не работает, вы обычно увидите:

• Ошибки NXDOMAIN (домен не существует)
• Таймауты соединения (резолвер недоступен)
• Ответы SERVFAIL (проблемы с upstream-сервером)

В браузерах они появляются как “DNS_PROBE_FINISHED_NXDOMAIN” или подобные ошибки. В Node.js или других runtime вы получите исключения ENOTFOUND или эквивалентные.

Используйте dig или nslookup для отладки. Запрашивайте разные резолверы, чтобы изолировать проблему: локальное кэширование, ваш резолвер или авторитетные серверы.

Заключение

DNS находится между вашими пользователями и вашими серверами. Понимание процесса разрешения, поведения TTL и современных протоколов, таких как HTTPS-записи и DoH, помогает вам развёртывать более надёжно и отлаживать быстрее. Когда что-то ломается, DNS должен быть одним из ваших первых подозреваемых — не последним.

Часто задаваемые вопросы

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.