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