Когда преобразователь DNS ищет домен/зону для авторитетного сервера имен, принимает ли он все 6 записей и циклически перебирает их?
Да, правильный рекурсивный сервер имен учитывает все серверы имен и каждый раз будет пытаться запрашивать самый быстрый из них.
Примерный алгоритм такой:
- с холодного старта (без кеша), попробуйте все из них в случайном порядке, запишите, как быстро они отвечают (вам может потребоваться отделить случай UDP от случая TCP)
- через какое-то время начните чаще использовать самый быстрый на основе предыдущих ответов
- но обратите внимание, что вам нужно убедиться, что вы не привязаны на неопределенный срок к какому-либо заданному серверу имен, вам нужно «время от времени» пробовать и другие. Почему? Потому что топология сети может меняться, как и сами серверы имён.
нс3 может быть быстрее сегодня для вашей конкретной точки зрения, но, возможно, завтра нс5 вместо; поэтому вы должны использовать самый быстрый, но не всегда, просто чтобы иметь возможность автоматически обнаруживать любой другой быстрее, чем тот, который вы считаете самым быстрым прямо сейчас.
Если резолвер использует 1-й NS-сервер
Остановись здесь. Записи идут набором, а не списком. То есть в DNS нет внутреннего порядка. Конечно есть порядок в проводном или дисплейном представлении, но он не исходит из протокола.
Наборы пластинок - это мешки: вы получаете пластинки без заказов. На самом деле, вы можете видеть, что многие серверы имен для одного и того же запроса, если в ответе есть несколько записей, будут упорядочивать записи по-разному каждый раз, когда вы запрашиваете, именно для борьбы с клиентскими системами, которые будут учитывать только первый элемент и пренебрегать остальными.
когда этот авторитетный сервер имен не отвечает
См. алгоритм выше: если один из серверов имён в NS set не отвечает, вы можете считать, что это то же самое, что «отвечать как самый медленный из любого другого». У клиентского DNS есть тайм-ауты, поэтому он не будет ждать бесконечно, но отметит, что этот конкретный сервер имен работает слишком медленно, и переключится на другие.
Таким образом, в первый раз вы подвергаетесь штрафу, потому что система должна попытаться связаться с этим сервером имен, немного подождать (несколько секунд), повторить попытку и в какой-то момент перестать использовать этот сервер имен. После этого рампы он будет использовать другие серверы имен, и все будет быстро. Но в первый раз, когда вам нужно обнаружить, что данный сервер имен работает медленно/не отвечает, пытаясь связаться с ним, вы не можете сделать вывод о проблеме, не пытаясь.
Означает ли это, что мне нужно установить короткий TTL для записей NS?
Возможно, но в основном это не имеет значения. Почему? Потому что ваш NS записи публикуются в родительской зоне вашего домена, чтобы обеспечить делегирование DNS. Они публикуются там с TTL, конечно, так как все записи имеют прикрепленный к ним TTL, но они публикуются в зоне, которую вы не контролируете, поэтому вы НЕ можете выбирать их значения TTL!
(Здесь есть сложная/не до конца законченная дискуссия об этих записях, например NS которые существуют в двух частях: родительской и дочерней, с вопросом «какая из них действительно авторитетна»? Если у родителя есть TTL 1 неделя на NS записи и вы в своей зоне такие же NS записи имеют TTL 1 секунду, что должен делать рекурсивный сервер имен? Можно прийти к выводу, что обычно дочерняя часть делегации является авторитетной, поэтому здесь выигрывает 1 секунда; на практике несколько реализаций DNS «ориентированы на родителей», то есть они используют данные на родительской стороне, поэтому здесь выигрывает 1 неделя)
TTL — это всегда компромисс. Узнав об этом, некоторые люди сразу же делают вывод, что все работает лучше с очень низким значением TTL... что верно для некоторых случаев и не очень для других. Кэши — это хорошо, если бы их не было (иначе: не использовались достаточно большие TTL), вы не были бы устойчивы к любым небольшим проблемам, из-за которых все исчезло бы, потому что имена кешей уже истекли бы.
Кроме того, значение TTL не влияет (или оказывает незначительное влияние) на описанный выше алгоритм при циклическом обходе всех серверов имен, попытках с тайм-аутом и сходимости на самом быстром.
Итак, если вы посмотрите, что происходит в серверах имен TLD (этот хост NS записи для всех доменов в этом TLD) или в различных рекомендациях, вы часто будете видеть NS записи с TTL 1 или 2 дня.
Любые советы о том, как DNS-преобразователь работает с не отвечающим NS и его TTL?
Каждый преобразователь делает свое собственное :-) На самом деле это не указано в протоколе, это деталь реализации. Вы можете изучить исходный код того, который сможете установить, но, вероятно, не сможете получить информацию об этом от крупных общедоступных поставщиков рекурсивных DNS.
Вы можете найти более подробную информацию здесь:
RFC 1034 §5.3.3 также дает некоторую информацию (обратите внимание, что он учитывает один случай, о котором вы забыли: данный сервер имен может иметь несколько IP-адресов - сегодня даже это всегда должно быть, с одним IPv4 и одним IPv6 - и нет никакой гарантии, что вы получите результаты за одинаковое время с каждым):
Помимо имен и адресов серверов, данные SLIST
структуру можно отсортировать, чтобы в первую очередь использовать лучшие серверы и обеспечить
что все адреса всех серверов используются в циклическом режиме.
сортировка может быть простой функцией предпочтения адресов на локальном
сеть по сравнению с другими или может включать статистику прошлых событий, например
предыдущее время отклика и средние показатели.
Шаг 3 отправляет запросы до тех пор, пока не будет получен ответ. Стратегия
циклически перебирать все адреса для всех серверов с
тайм-аут между каждой передачей. На практике важно использовать
все адреса многосетевого хоста и слишком агрессивная повторная передача
политика фактически замедляет отклик при использовании несколькими распознавателями
бороться за один и тот же сервер имен и даже иногда за один
резольвер. SLIST обычно содержит значения данных для управления тайм-аутами.
и отслеживать предыдущие передачи.
RFC 1035 §7.2 говорит следующее:
Чтобы завершить инициализацию SLIST, преобразователь прикрепляет все
информация об истории, которую он имеет для каждого адреса в SLIST. Это будет
обычно состоят из своего рода средневзвешенных значений времени отклика
адреса и среднее значение адреса (т. е. как часто
адрес ответил вообще на запрос). Обратите внимание, что это
информация должна храниться по адресам, а не по
сервера имен, потому что время отклика и среднее значение
конкретный сервер может значительно отличаться от адреса к адресу. Запись
также, что эта информация на самом деле специфична для адреса резолвера /
пара адресов сервера, поэтому преобразователь с несколькими адресами может захотеть
вести отдельные истории для каждого из своих адресов. Часть этого шага
должен иметь дело с адресами, которые не имеют такой истории; в этом случае
ожидаемое время прохождения туда-обратно 5-10 секунд должно быть наихудшим случаем, с
более низкие оценки для той же локальной сети и т.д.
Обратите внимание, что всякий раз, когда следует делегирование, алгоритм распознавателя
повторно инициализирует SLIST.
Информация устанавливает частичное ранжирование доступного имени
адреса серверов. Каждый раз, когда выбирается адрес, и состояние должно
быть изменено, чтобы предотвратить его повторный выбор, пока все другие адреса не будут
был опробован. Таймаут для каждой передачи должен быть на 50-100% больше
чем среднее прогнозируемое значение, чтобы учесть отклонение в ответе.
Также, чтобы закончить и более конкретно об этом:
Как показано в этой статье от imperva
В этой статье, на которую вы ссылаетесь, рассказывается о проблеме, которая возникла у людей, использующих серверы имен Dyn, когда произошел сбой.
Тогда да, если вы используете только серверы имен Dyn, у вас есть проблема. Даже если вы измените свою зону, чтобы использовать другие, NS Records TTL означает, что ваше изменение не будет видно сразу. Но на самом деле это ничего не говорит о TTL, но много говорит об управлении DNS: если вы хотите быть устойчивым, для важных зон используйте не одного провайдера DNS, а несколько (что, конечно, требует некоторой координации между их вы не можете просто произвольно смешивать и сопоставлять провайдерам X и Y, и это еще сложнее, если вы через DNSSEC в микс, но возможно).
Таким образом, именно из-за алгоритма, быстро составленного выше, даже если 2 из 5, скажем, серверов имен, не отвечают полностью, потому что у этого конкретного провайдера есть проблема, другой возьмет на себя нагрузку и заставит ваш домен работать.Может быть дополнительная задержка при каждом новом запросе посетителей (потому что все рекурсивные серверы имен не могут сразу понять, что им нужно переключиться на определенные серверы имен, потому что 2 из 5 не работают), а также больше задержек, потому что остальные 3 перегружены большим количеством запросы, чем обычно (DNS балансирует нагрузку по умолчанию, поэтому теоретически каждый сервер имен получает примерно одинаковый объем запросов), но все же ответ будет дан.
PS: не запрашивается, но иногда непонятно, все записи в данном наборе записей должны иметь одинаковый TTL. TTL указан для каждой записи, но должен быть одинаковым в данном наборе записей, что означает для данного кортежа (имя, тип записи) [и класс, но никто не использует ничего, кроме В как класс]
