A и AAAA: наличие двух адресов не гарантирует быстрое подключение клиента
Фотография конкретного исполнения не приложена.
Клиент с IPv4 и IPv6 должен учитывать независимость DNS-ответов и сетевых путей двух семейств. RFC 8305 описывает Happy Eyeballs: запросы выполняются близко по времени, а подключение не обязано ждать завершения обоих ответов. Цель — не блокировать пригодный путь из-за задержки другой семьи.
Попытки подключения запускаются с предусмотренным разнесением, а не бесконтрольным одновременным открытием всех адресов. После успешного соединения лишние попытки прекращаются по алгоритму. Поддержку такого поведения нужно подтвердить у приложения или его сетевой библиотеки: наличие записей A и AAAA в зоне само по себе его не включает.
В проекте отдельно наблюдают DNS-задержку и время установления транспорта. Клиент способен получить оба корректных ответа, но долго ждать неработающий предпочитаемый путь. Отключение одного семейства без диагностики скрывает причину и не объясняет, как будет работать резервирование при другом отказе.
В приёмке проверяют доступные оба пути, задержанный DNS-ответ и согласованную недоступность одного семейства. Измеряют время фактического подключения и выбранный адрес. Успешный одиночный запрос к DNS не подтверждает пригодную задержку двустекового клиента при частичной неисправности сети.
Основание — Selected IETF DNS RFCs, exact numbers and sections cited; Linux/glibc manual where explicitly stated, разделы RFC8305 §3 Hostname Resolution; §5 Connection Attempts. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Реальные зоны, resolver и HTTP-клиенты не испытывались. Это проектные критерии; номера RFC обозначают документы, а не подтверждённую поддержку всех возможностей конкретным устройством.
Запросы отправляются на наш e-mail из вашей почтовой программы.
