Что такое DNS

DNS отвечает на вопрос: какие данные связаны с этим доменным именем. Чаще всего браузеру нужен IP-адрес, чтобы подключиться к серверу. Поэтому пользователь вводит example.com, а не запоминает адрес вроде 203.0.113.10.

На интервью не останавливайтесь только на аналогии с телефонной книгой. Скажите, что DNS распределен. Ответ может прийти из кеша, от рекурсивного резолвера или через цепочку серверов, которая приводит к авторитетному серверу домена.

Практический вывод простой: если DNS не сработал, HTTP-запрос еще не начался. Вы не получите нормальный ответ API, HTML-страницу или HTTP-статус. Для пользователя это выглядит как недоступный сайт. Для фронтенда это сетевой сбой до приложения.

Упрощенная цепочка такая. Браузер или ОС сначала проверяет кеш. Если ответа нет, запрос уходит к рекурсивному резолверу. Это может быть резолвер провайдера, корпоративной сети или публичный DNS. У резолвера тоже может быть кеш. Если кеша нет, он ищет ответ через корневые серверы, TLD-серверы и авторитетные серверы нужного домена.

После получения адреса браузер открывает соединение. Для HTTPS дальше идет TLS-рукопожатие и проверка сертификата для имени хоста. Только после этого начинается HTTP-запрос. Поэтому не стоит говорить, что если DNS работает, то сайт полностью настроен. Еще могут сломаться TLS, серверная конфигурация, CORS, cookies или приложение.

В ответе не нужно перечислять все типы записей. Достаточно назвать самые частые и связать их с задачами. A и AAAA ведут к адресам. CNAME делает алиас на другое имя. TXT часто нужен для подтверждения домена или политик безопасности.

Важная ловушка: CNAME не является HTTP-редиректом. Он не меняет путь, не добавляет https, не отправляет статус 301 и не управляет маршрутом внутри SPA. Если нужно перенести /old-page на /new-page, это делают на уровне сервера, CDN, edge-функции или приложения.

TTL, или Time To Live, показывает, как долго DNS-ответ можно хранить в кеше. Это не гарантия мгновенного обновления у всех пользователей. Это настройка времени жизни ответа. Если до переезда у записи был большой TTL, старые адреса могут жить в кешах еще какое-то время.

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

Пример проверки:

dig example.com A
dig example.com CNAME
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Такой пример показывает не только адрес. Он также показывает, что разные резолверы могут отвечать по-разному во время изменения записей.

DNS-ошибка в браузере обычно приходит в приложение как сетевая ошибка, если запрос делает ваш код. Это не ответ API. У него нет надежного status, тела JSON и серверного сообщения. Поэтому опасно писать обработчик, который для любой ошибки делает await response.json() или показывает, что сервер вернул 500.

Безопаснее разделять два случая. Если ответ пришел, проверяйте response.ok и статус. Если запрос упал до ответа, показывайте понятный error state: нет соединения, домен недоступен или сервис временно недоступен. Кнопка повтора полезна, но не запускайте бесконечные повторы без паузы. Это ухудшает UX и создает лишние запросы, когда сеть восстановится.

В React также важно отменять запрос через AbortController или игнорировать устаревший результат при размонтировании и смене параметров. DNS сам по себе не вызывает race condition, но сетевые сбои и повторы легко приводят к неверному состоянию UI, если старый запрос перезапишет новый результат.

На интервью можно ответить так:

DNS это система доменных имен. Она помогает клиенту по имени вроде example.com получить адрес или другую запись. После этого клиент открывает соединение и делает HTTP-запрос. DNS распределен и кешируется, поэтому изменения записей не всегда видны всем пользователям сразу. Для фронтенда это важно при деплое, подключении CDN, настройке домена, TLS и диагностике ошибок, когда запрос до API вообще не дошел.

Это короткая формулировка, но в ней есть главное: назначение DNS, место в сетевой цепочке, кеширование и практическая связь с фронтендом.

Еще один частый сценарий связан с фронтенд-хостингом. Вы добавляете домен в Vercel, Netlify, Cloudflare Pages или другой сервис. Сервис просит создать CNAME, A или TXT. Если запись сделана неверно или еще не обновилась в кеше, в панели будет ошибка валидации домена, а сайт может открываться только по техническому адресу.

В ответе полезно сказать, что DNS решает только часть задачи. После успешного резолвинга нужно проверить сертификат, настройки хоста, правила CDN, заголовки, CORS и cookies для нужного домена.