Как резолвится домен, прежде чего браузер отправит первый байт

Вопрос звучит безобидно: «что происходит, когда вы вводите адрес в браузер». На деле проверяют, понимаете ли вы, что DNS — это не один запрос, а цепочка с кэшами на каждом уровне.

Браузер сначала смотрит в свой собственный кэш (у Chrome он отдельный от ОС). Если записи нет — идёт в ОС, у той тоже есть кэш резолвера. Если и там пусто — запрос улетает рекурсивному резолверу: это может быть DNS провайдера или публичный вроде 8.8.8.8 и 1.1.1.1.

Рекурсивный резолвер делает всю грязную работу сам: спрашивает корневой сервер («кто обслуживает .com»), потом сервер зоны .com («кто обслуживает example.com»), потом авторитативный сервер домена, который и отдаёт финальный A-запись или CNAME. Клиент все эти шаги не видит — только итоговый ответ.

TTL записи решает, сколько это проживёт в кэше. Короткий TTL — свежие данные при смене IP, но больше нагрузки на резолверы. Длинный — быстрее для клиентов, но смена сервера распространяется медленно.

// на уровне JVM свой кэш DNS, отдельно от ОС InetAddress.getByName("example.com"); // TTL кэша JVM — networkaddress.cache.ttl, // по умолчанию кэширует до перезапуска JVM

Следующий вопрос обычно про то, почему JVM по умолчанию кэширует успешный резолв DNS навсегда (networkaddress.cache.ttl = -1 без SecurityManager), и что происходит, если IP у сервиса за балансировщиком сменился, а джава-приложение продолжает стучаться по старому адресу. Это реальная причина таймаутов после failover, которую не видно в логах самого приложения.

Резолв домена — это не один хоп, а минимум три кэша и потенциально пять сетевых round-trip, прежде чем начнётся TCP-хендшейк.

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки