DNS-резолвер против записи NS TTL

Question

Когда DNS-резолвер ищет в домене/зоне авторитетный сервер имен, принимает ли он все 6 записей и циклически перебирает их?

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

Грубый алгоритм выглядит примерно так:

с холодного старта (без кэша), попробуйте все из них в случайном порядке, запишите, как быстро они отвечают (вам может потребоваться отделить случай UDP от случая TCP)
через некоторое время начните чаще использовать самый быстрый из них, исходя из предыдущих ответов
но учтите, что вам нужно убедиться, что вы не застрянете на каком-то определенном сервере имен, вам придется "время от времени" пробовать и другие. Почему? Потому что топология сети может измениться, как и сами серверы имен. ns3может быть быстрее сегодня для вашей конкретной точки обзора, но может быть и завтра ns5; поэтому вам нужно использовать самый быстрый, но не всегда, просто чтобы быть уверенным, что вы сможете автоматически обнаружить любой другой быстрее, чем тот, который вы считаете самым быстрым в данный момент.

Если резолвер использует 1-й NS-сервер

Остановитесь здесь. Записи поступают в наборе, а не списке. То есть в DNS нет внутреннего порядка. Конечно, есть порядок в проводном или дисплейном представлении, но он не исходит из протокола.

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

когда этот авторитетный сервер имен не отвечает

См. алгоритм выше: если один из серверов имен в наборе NSне отвечает, вы можете считать это тем же самым, что и «ответ как самый медленный от любого другого». Клиентский DNS имеет тайм-ауты, поэтому он не будет ждать бесконечно, а отметит этот конкретный сервер имен как слишком медленный и переключится на другие. Таким образом, в первый раз вы несете штраф, потому что система должна попытаться связаться с этим сервером имен, немного подождать (несколько секунд), повторить попытку и в какой-то момент прекратить использование этого сервера имен. После этого скачка она будет использовать другие серверы имен, и все будет быстро. Но в первый раз, когда вам придется обнаружить, что определенный сервер имен работает медленно/не отвечает, действительно попытавшись связаться с ним, вы не сможете сделать вывод о проблеме, не попытавшись.

Означает ли это, что мне нужно установить короткий TTL для записей NS?

Может быть, но это в основном не имеет значения. Почему? Потому что ваши NSзаписи публикуются в родительской зоне вашего домена, чтобы обеспечить делегирование DNS. Они публикуются там с TTL, конечно, так как все записи имеют прикрепленный к ним TTL, но они публикуются в зоне, которую вы не контролируете, поэтому вы НЕ можете выбирать их значения TTL!

(Здесь идет сложная/не полностью законченная дискуссия об этих записях, например, о NSтом, что они существуют в двух частях: родительской и дочерней, с вопросом «какая из них действительно авторитетна»? Если у родительской NSзаписи TTL составляет 1 неделю, а у вас в зоне те же NSзаписи имеют TTL в 1 секунду, что должен делать рекурсивный сервер имен? Можно прийти к выводу, что обычно дочерняя часть делегирования ЯВЛЯЕТСЯ авторитетной, поэтому здесь побеждает 1 секунда; на практике множественные реализации DNS «ориентированы на родителя», то есть они используют данные на родительской стороне, поэтому там побеждает 1 неделя)

TTL всегда являются компромиссами. Узнав об этом, некоторые люди сразу же приходят к выводу, что все работает лучше с очень низкими TTL... что верно для некоторых случаев и не очень верно для других. Кэши хороши, если бы их не было (т. е. не использовались бы достаточно большие TTL), вы не были бы устойчивы к любым мелким проблемам, которые бы заставили все исчезнуть, потому что кэши уже бы устарели для имен.

Кроме того, значение TTL не оказывает (или оказывает незначительное) влияние на описанный выше алгоритм при циклическом переборе всех серверов имен, попытке определить время ожидания и выборе самого быстрого из них.

Поэтому, если вы посмотрите на то, что происходит на серверах имен TLD (где размещены NSзаписи для всех доменов в этом TLD) или в различных рекомендациях, вы часто увидите NSзаписи со сроком жизни 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записи TTL означают, что ваши изменения не будут видны немедленно. Но на самом деле это не говорит много о TTL, а просто говорит много об управлении DNS: если вы хотите быть устойчивыми, для важных зон не используйте одного поставщика DNS, а несколько (что, конечно, требует некоторой координации между ними, вы не можете просто произвольно смешивать и сопоставлять поставщиков X и Y, и это еще сложнее, если вы используете DNSSEC в миксе, но это возможно). Таким образом, именно из-за алгоритма, быстро составленного выше, даже если 2 из 5, скажем, серверов имен не отвечают полностью из-за того, что у этого конкретного поставщика возникла проблема, другой возьмет на себя нагрузку и заставит ваш домен работать. При каждом новом запросе посетителей может возникнуть дополнительная задержка (поскольку все рекурсивные серверы имен не могут сразу понять, что им нужно переключиться на определенные серверы имен, поскольку 2 из 5 не работают), а также еще большие задержки из-за того, что остальные 3 перегружены большим количеством запросов, чем обычно (DNS по умолчанию балансирует нагрузку, поэтому теоретически каждый сервер имен получает примерно одинаковый объем запросов), но ответ все равно будет дан.

PS: не просили, но так как это иногда не ясно, все записи в данном наборе записей должны иметь одинаковый TTL. TTL для каждой записи, но должен быть одинаковым в данном наборе записей, что означает для данного кортежа (имя, тип записи) [и класс, но никто не использует ничего, кроме INкак класс]

Answer 1

Когда DNS-резолвер ищет в домене/зоне авторитетный сервер имен, принимает ли он все 6 записей и циклически перебирает их?

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

Грубый алгоритм выглядит примерно так:

с холодного старта (без кэша), попробуйте все из них в случайном порядке, запишите, как быстро они отвечают (вам может потребоваться отделить случай UDP от случая TCP)
через некоторое время начните чаще использовать самый быстрый из них, исходя из предыдущих ответов
но учтите, что вам нужно убедиться, что вы не застрянете на каком-то определенном сервере имен, вам придется "время от времени" пробовать и другие. Почему? Потому что топология сети может измениться, как и сами серверы имен. ns3может быть быстрее сегодня для вашей конкретной точки обзора, но может быть и завтра ns5; поэтому вам нужно использовать самый быстрый, но не всегда, просто чтобы быть уверенным, что вы сможете автоматически обнаружить любой другой быстрее, чем тот, который вы считаете самым быстрым в данный момент.

Если резолвер использует 1-й NS-сервер

Остановитесь здесь. Записи поступают в наборе, а не списке. То есть в DNS нет внутреннего порядка. Конечно, есть порядок в проводном или дисплейном представлении, но он не исходит из протокола.

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

когда этот авторитетный сервер имен не отвечает

См. алгоритм выше: если один из серверов имен в наборе NSне отвечает, вы можете считать это тем же самым, что и «ответ как самый медленный от любого другого». Клиентский DNS имеет тайм-ауты, поэтому он не будет ждать бесконечно, а отметит этот конкретный сервер имен как слишком медленный и переключится на другие. Таким образом, в первый раз вы несете штраф, потому что система должна попытаться связаться с этим сервером имен, немного подождать (несколько секунд), повторить попытку и в какой-то момент прекратить использование этого сервера имен. После этого скачка она будет использовать другие серверы имен, и все будет быстро. Но в первый раз, когда вам придется обнаружить, что определенный сервер имен работает медленно/не отвечает, действительно попытавшись связаться с ним, вы не сможете сделать вывод о проблеме, не попытавшись.

Означает ли это, что мне нужно установить короткий TTL для записей NS?

Может быть, но это в основном не имеет значения. Почему? Потому что ваши NSзаписи публикуются в родительской зоне вашего домена, чтобы обеспечить делегирование DNS. Они публикуются там с TTL, конечно, так как все записи имеют прикрепленный к ним TTL, но они публикуются в зоне, которую вы не контролируете, поэтому вы НЕ можете выбирать их значения TTL!

(Здесь идет сложная/не полностью законченная дискуссия об этих записях, например, о NSтом, что они существуют в двух частях: родительской и дочерней, с вопросом «какая из них действительно авторитетна»? Если у родительской NSзаписи TTL составляет 1 неделю, а у вас в зоне те же NSзаписи имеют TTL в 1 секунду, что должен делать рекурсивный сервер имен? Можно прийти к выводу, что обычно дочерняя часть делегирования ЯВЛЯЕТСЯ авторитетной, поэтому здесь побеждает 1 секунда; на практике множественные реализации DNS «ориентированы на родителя», то есть они используют данные на родительской стороне, поэтому там побеждает 1 неделя)

TTL всегда являются компромиссами. Узнав об этом, некоторые люди сразу же приходят к выводу, что все работает лучше с очень низкими TTL... что верно для некоторых случаев и не очень верно для других. Кэши хороши, если бы их не было (т. е. не использовались бы достаточно большие TTL), вы не были бы устойчивы к любым мелким проблемам, которые бы заставили все исчезнуть, потому что кэши уже бы устарели для имен.

Кроме того, значение TTL не оказывает (или оказывает незначительное) влияние на описанный выше алгоритм при циклическом переборе всех серверов имен, попытке определить время ожидания и выборе самого быстрого из них.

Поэтому, если вы посмотрите на то, что происходит на серверах имен TLD (где размещены NSзаписи для всех доменов в этом TLD) или в различных рекомендациях, вы часто увидите NSзаписи со сроком жизни 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записи TTL означают, что ваши изменения не будут видны немедленно. Но на самом деле это не говорит много о TTL, а просто говорит много об управлении DNS: если вы хотите быть устойчивыми, для важных зон не используйте одного поставщика DNS, а несколько (что, конечно, требует некоторой координации между ними, вы не можете просто произвольно смешивать и сопоставлять поставщиков X и Y, и это еще сложнее, если вы используете DNSSEC в миксе, но это возможно). Таким образом, именно из-за алгоритма, быстро составленного выше, даже если 2 из 5, скажем, серверов имен не отвечают полностью из-за того, что у этого конкретного поставщика возникла проблема, другой возьмет на себя нагрузку и заставит ваш домен работать. При каждом новом запросе посетителей может возникнуть дополнительная задержка (поскольку все рекурсивные серверы имен не могут сразу понять, что им нужно переключиться на определенные серверы имен, поскольку 2 из 5 не работают), а также еще большие задержки из-за того, что остальные 3 перегружены большим количеством запросов, чем обычно (DNS по умолчанию балансирует нагрузку, поэтому теоретически каждый сервер имен получает примерно одинаковый объем запросов), но ответ все равно будет дан.

PS: не просили, но так как это иногда не ясно, все записи в данном наборе записей должны иметь одинаковый TTL. TTL для каждой записи, но должен быть одинаковым в данном наборе записей, что означает для данного кортежа (имя, тип записи) [и класс, но никто не использует ничего, кроме INкак класс]

DNS-резолвер против записи NS TTL

решение1

Связанный контент