У домена может быть много серверов имен, зарегистрированных у регистратора домена. Серверы имен выбираются случайным образом, а не так, как ожидалось: первичный первый, вторичный второй и так далее.
Зная это, означает ли это, что, когда один сервер имен не работает, существует 50% -ная вероятность того, что посетители, которые задают вопросы автономному серверу имен, никогда не достигнут вашего сайта? В то время как остальные 50% могут нормально просматривать ваш сайт, что влияет на доступность сервера?
Наконец, почему клиенты по умолчанию не опрашивают следующий сервер имен в списке, когда один из них не работает?
То же самое касается IPv4 и IPv6. Если один из серверов имен поддерживает только IPv6 и не поддерживает IPv4, и пользователь без подключения к IPv6 задается вопросом об этом конкретном сервере имен, я полагаю, что сайт будет недоступен.
Кроме того, я подробно говорю о способе выбора авторитетного сервера и обработке сбоя в случае, если выбранный авторитетный сервер недоступен из-за простоя или несовместимости ipv4-ipv6 между клиентом и сервером.
Наконец, почему клиенты по умолчанию не опрашивают следующий сервер имен в списке, когда один из них не работает?
Именно это и делают рекурсивные серверы при разговоре с авторитетными серверами. RFC 1035 §7.2 описывает общий процесс, если вам интересно, но следующие отрывки являются наиболее важными:
Ключевой алгоритм использует информацию о состоянии запроса, чтобы выбрать следующий адрес сервера имен для запроса, а также вычисляет тайм-аут, который вызовет следующее действие, если ответ не поступит. Следующим действием обычно будет передача на другой сервер, но это может быть временная ошибка для клиента.
[вырезать]
- Если преобразователь получает ошибку сервера или другой странный ответ от сервера имен, он должен удалить его из SLIST и, возможно, пожелает запланировать немедленную передачу на следующий адрес сервера-кандидата.
При выборе авторитетного сервера учитывается еще несколько факторов, например, наблюдаемое время ответа на основе предыдущей истории связи. Это есть в RFC, если вам интересно.
Ключ к обеспечению того, чтобы на вас не влияла недоступность сервера имен, содержится в BCP 16. В частности, Раздел 3.1 состояния:
Вторичные серверы должны быть размещены как в топологически, так и в географически удаленных местах в Интернете, чтобы свести к минимуму вероятность того, что единичный сбой приведет к их отключению.
То есть вторичные серверы должны находиться в географически удаленных местах, поэтому маловероятно, что такие события, как потеря питания и т. Д., Нарушат их работу всех одновременно. Они также должны быть подключены к сети различными путями. Это означает, что отказ любого одного канала или маршрутизации в каком-либо сегменте сети (например, у поставщика услуг) не сделает все серверы недоступными.
Это сделано для того, чтобы учесть тот факт, что на отказоустойчивость вашего домена серьезно влияют единичные точки отказа в сети или на физическом сайте. Идеальное состояние - иметь несколько авторитетных серверов имен, на которые не влияют никакие изменения в сети или физическом состоянии, испытываемые другими.
Я бы сказал, что ответ на общую тональность вопроса - «нет».
Во-первых, клиентская машина традиционно имеет только преобразователь заглушек, слепо отправляющий все запросы (с установленным параметром «желаемая рекурсия») на некоторый настроенный адрес сервера имен (resolv.conf).
Это действительно то, что происходит на следующем шаге, когда этот сервер имен обрабатывает запрос на рекурсию, выполняя итеративные запросы, пока он не достигнет авторитета, что ваш вопрос применим.
И хотя существует некоторая степень специфического для реализации поведения, абсолютно точно ожидается, что он попытается работать через авторитетные серверы имен, пока не найдет тот, который реагирует.
Предостережение здесь скорее в том, что будет некоторый общий тайм-аут, поэтому есть риск, что он не может закончиться вовремя.
Тем не менее, также принято следить за тем, какие серверы работают, а какие нет, что увеличивает шансы на то, что последовательные запросы будут успешными в своевременном режиме, и, конечно, запросы для уже кэшированных данных даже не потребуют связи с авторитетными серверами.
В общем, нет, вы не должны ожидать 50% вероятности появления видимой пользователем ошибки, если есть два сервера имен и один не работает. Скорее всего, первый поиск в сценарии с полностью холодным кешем будет немного медленным.
Утверждение, что существует 50% -ная вероятность того, что посетители, которые задают вопрос автономному серверу имен, никогда не достигнут вашего сайта, не является точным. Из руководства распознавателя Linux man resolv.conf, в разделе, описывающем nameserver вариант вы можете прочитать:
Если серверов несколько, библиотека распознавателя запрашивает их в указанном порядке. Если записи о сервере имен отсутствуют, по умолчанию используется сервер имен на локальном компьютере. Используемый алгоритм состоит в том, чтобы попробовать сервер имен, и, если время запроса истекает, попробуйте следующий, пока не закончатся серверы имен, затем повторите попытку всех серверов имен, пока не будет выполнено максимальное количество повторных попыток.
Таким образом, они будут проверяться в соответствии с порядком, указанным в файле конфигурации. Это не обязательно означает, что все резолверы должны вести себя одинаково.