Подтвердить что ты не робот

Использование DNS для перехода на другой ресурс с использованием нескольких записей A

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

Итак, я попробовал протестировать его:

  • Я загрузил страницу из нашего домена
  • Отметьте, какой из наших серверов обслуживал страницу
  • Отключил веб-сервер на этом хосте
  • Перезагрузка страницы

И действительно, браузер автоматически попробовал другой сервер для загрузки страницы. Это работало в Opera, Safari, IE и Firefox. Только Chrome не смог попробовать другой сервер.

Но после оставления этого сервера в автономном режиме в течение нескольких минут и просмотра журналов доступа, я обнаружил, что количество запросов на другие серверы значительно не увеличилось. С 1 из 3 серверов в автономном режиме я ожидал, что доступ к каждому из оставшихся 2 серверов будет примерно расти на 50%, но вместо этого я видел только 7-10%. Это может означать только переход на другой ресурс DNS для большинства браузеров/посетителей, что прямо противоречит тому, что я только что испытал.

Есть ли у кого-нибудь идея, что происходит с переходом на веб-браузер DNS-based? Какая возможная причина может быть связана с тем, почему автоматический переход на другой ресурс работает для меня, но не для большинства наших посетителей?

4b9b3361

Ответ 1

Что происходит, так это то, что браузеры не выполняют автоматическое переключение DNS.

Если у вас несколько записей A в домене, тогда, когда ваш сервер имен запрашивает IP-адрес для домена, который вы ввели в ваш браузер, он запросит его у SOA. Это может быть любая из этих записей A. Затем он передает его.

Некоторые серверы имен достаточно "умны", чтобы запросить новую запись A, если тот, который она получает, не работает, а некоторые нет. Поэтому, если вы установили несколько записей A, вы настроите переход на резервный псевдоним, но только для тех людей с "умными" серверами имен. Остальные получают бросок кубиков, на которых они получают IP, и если он работает тогда хорошо, а если нет, то он не будет загружаться, как это было для вас в Chrome.

Если вы хотите специально протестировать это, вы можете использовать файл hosts C:\Windows\system32\drivers\etc\hosts в Windows и /etc/hosts в Linux, чтобы указать, какой IP-адрес вы хотите использовать в каком домене, чтобы узнать, действительно ли вы получаете истинное восстановление после сбоя, - как то, что вы будете практиковаться в том, что DNS-серверы по сети будут кэшировать ваше разрешение имен доменов на основе его TTL. Поэтому, если/когда вы получаете реальный сбой, этот IP-адрес все равно должен быть разрешен и иным образом обработан другим сервером имен.

Ответ 2

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

Кроме того, некоторые боты используют keep-alives, чтобы открыть TCP-соединения и сделать несколько HTTP-запросов по одному и тому же соединению. Учитывая, что поиск DNS выполняется только при подключении, они будут продолжать запрашивать старый IP-адрес по крайней мере до тех пор, пока соединение не будет открыто.

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

Ответ 3

то, что переводится в ip lookup, - это имя сервера имен, такого как ns1.domain.com, поэтому попробуйте вместо этого несколько записей ns, что гарантирует поиск не нескольких записей A. запись с несколькими A хороша только для распространения DNS или многоадресной рассылки против одноадресной. Google это то, что вы сделали, не отказоустойчивость. это многоадресная рассылка. аварийное переключение работает, если DNS-серверы копируют друг друга все время как ведущий-ведомый. https://mcpmag.com/articles/2004/05/01/10-dns-errors-that-will-kill-your-network.aspx