Использование нескольких A-записей для моего домена - пробуют ли когда-нибудь веб-браузеры более одной?

Если я добавлю несколько A-записей для своего домена, они будут возвращены DNS-серверами в циклическом порядке.

Пример:

192.0.2.1 A example.com
192.0.2.2 A example.com
192.0.2.3 A example.com

Но как веб-браузеры реагируют, если первый хост ( 192.0.2.1) не работает (недоступен)? Они пробуют второй хост ( 192.0.2.2) или возвращают сообщение об ошибке пользователю? Есть ли разница между самыми популярными браузерами?

Если я реализую свое собственное приложение, я смогу реализовать его так, чтобы второе использовалось, если первое не работает, так что это возможно. И это было бы очень полезно для создания отказоустойчивого веб-сайта.

Да, большинство браузеров за последние 5-10 лет пробуют другие записи A, если один из них не отвечает. Это иногда называется «попытка браузера» или «попытка клиента». Вы в значительной степени только найти материал об этом в контексте различных браузеров подвигов , которые эта функция позволяет с сайтами , не используя его (см DNS переприсваивания и DNS пиннинг , анти-Dns пиннинг, анти-анти-Dns пиннинг, анти-анти -анти-днс пиннинг и тд). Вид плохой репутации, но это доказывает, что она существует.

Практически каждый браузер действительно получает полный список записей А и действительно проверяет другие, не работает ли одна из них. Можно ожидать, что у каждого клиента будет 30-секундное ожидание при первой попытке доступа к сайту, когда сервер не работает, пока он не подключится к рабочему адресу. Браузер затем кеширует, какой адрес работает, и продолжит использовать этот адрес для будущих запросов, если только он не завершится с ошибкой, затем ему придется снова выполнить поиск по списку. Так что 30 секунд ожидания по первому запросу, штраф в дальнейшем.

Но это не то, что вы обязательно хотите использовать, у него будет много предостережений по поводу совместимости браузера, совместимости с ОС, прокси-совместимости, заголовков контроля кэша, которые будут иметь странные последствия, независимо от того, запоминает ли он, какие IP-адреса отключены или начинает иметь в течение 30 секунд ожидания при каждом запросе люди, пишущие пользовательские клиенты для вашего сайта, в конечном итоге будут использовать gethostbyname вместо getaddrinfo и не смогут справиться с отработкой отказа, всевозможными потенциальными проблемами.

Вы также не можете полагаться на несколько записей A, чтобы разрешить «главный» и «подчиненный» серверы, потому что вы никогда не будете знать, какой адрес браузер выберет из списка. Все они должны быть так же способны обрабатывать посетителей, если они бегут, потому что любой может получить трафик, если он работает. Браузер может подумать, что ваш третий сервер из списка является наиболее привлекательным, может быть, он выглядит ближе всего, и он выберет тот, хотя все три еще работают.

Но если вы можете жить с ограничениями и иметь достаточно простую систему HTTP, с которой вы можете предсказать взаимодействие браузера, это сработает.

О, вам также придется иметь дело со многими людьми, которые говорят вам, что этого не существует (поскольку это было правдой 15 лет назад). Но вы можете попробовать telnet-соединение с доменным именем с несколькими записями A, некоторые с мертвыми IP-адресами и некоторыми хорошими, если вам нужно это доказать (да, даже старый добрый telnet теперь использует getaddrinfo и обрабатывает несколько записей A в эти дни изящно) - он распечатает хороший список IP-адресов, которые он пробует, пока, наконец, не преуспеет.

Имейте в виду, что в Windows Vista реализованы глупые части RFC3484 (то есть обратная передача от IPV6 к IPV4), и они предпочитают IP-адрес, который разделяет большинство битов префикса с IP-адресом пользователя, а не выбирает один случайным образом. Поскольку у большинства пользователей IP-адреса начинаются с 192.168, это означает, что любой из ваших IP-адресов будет использовать большинство битов префикса, которые получат большую часть трафика Vista. Microsoft исправила этот специфический идиотизм в Windows 7 и более поздних версиях, так что это не такая большая проблема, как раньше.

Это базовый метод распределения балансировки нагрузки DNS: DNS Round Robin. Это не имеет ничего общего с браузером, это зависит от реализации распознавателя и локального / удаленного кэша адреса DNS. Изменения заключаются в том, что в случае сбоя сервера из-за кэширования на уровне DNS ваш веб-сайт может оказаться недоступным.

Смотрите здесь основное объяснение о Round Robin DNS на WikiPedia.

ОС определяет, какой IP использовать, а не браузер. Windows будет округлять список возврата (в списке, переданном из DNS), хотя будет продолжать использовать тот же адрес, пока DNS не будет сброшен или истечет время ожидания. * Реализации ix частично зависят от реализации связанного стека tcp, но обычно также следуют методу циклического перебора.