Короткий ответ
Приложение сначала проверяет локальный кэш (резолвер ОС, затем кэш браузера/системы), при отсутствии записи обращается к настроенному DNS-серверу (обычно через резолвер ОС), который возвращает IP-адрес, соответствующий домену, после чего приложение устанавливает соединение уже по полученному IP.
Как это работает подробнее
Системный резолвер на клиенте (stub resolver) отправляет рекурсивный запрос на сконфигурированный DNS-сервер (например, из /etc/resolv.conf), а этот сервер, если у него нет ответа в кэше, сам опрашивает корневые, затем TLD, затем авторитативные серверы домена, пока не получит окончательный ответ, и кэширует его на время TTL записи.
Пример кода
commands.sh
dig +short example.com
dig +short example.com @8.8.8.8Что использовать на практике
- Практика. для быстрой диагностики резолвинга используют dig или nslookup, сравнивая, что возвращает локальный резолвер и что возвращает публичный DNS (например 8.8.8.8) напрямую — это помогает отличить проблему локального кэша от проблемы самой DNS-записи.
Подводные камни
- Риск. Частая ошибка — сразу подозревать «сеть не работает», когда на самом деле не резолвится DNS-имя; стоит сначала проверить резолвинг отдельно от остальной сетевой связности (например, попробовать подключиться напрямую по IP).