Оптимизация значений TTL для сервиса DYNDNS

Вы написали:

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

Не могли бы вы немного прояснить, что вы пытаетесь достичь, регулируя значение TTL?

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

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

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

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

Я ожидаю, что это для относительно небольшого объема. Серверы, которым требуются большие объемы надежного поиска DNS, принадлежат статическому IP-адресу. Если это так, настройка TTL не должна быть такой важной.

Трудно дать хороший совет с частичной информацией. Следующие ответы сработали для меня. Поскольку у меня есть только ограниченная информация, ответ может быть неуместным в вашем случае.

При выборе TTL для этого случая я бы посмотрел TTL на источнике IP-адреса. Если вы используете DHCP с арендой более одной или двух минут, TTL в 10 секунд может быть экстремальным.

Если вы предоставляете внутреннюю услугу DYNDNS для клиентов DHCP, TTL составляет половину или четверть времени аренды. Ваш TTL для внешней службы, получающей свой адрес динамически, может потребоваться более короткий TTL.

Факторами, которые следует учитывать, будет то, где данные будут кэшироваться, как часто будут происходить изменения адреса и насколько важно, чтобы не было прерывания обслуживания. Вы также должны учитывать, где могут приземляться неверно подключенные соединения. Внутренние для организации или мертвые адреса, вероятно, менее важны, чем сервер в Интернете, который вы не можете контролировать.

РЕДАКТИРОВАТЬ:: Какой бы TTL вы ни указали, некоторые DNS-серверы будут игнорировать его как кеш для своих собственных TTL. Я полагаю, что это более вероятно с более короткими TTL. Несколько лет назад было множество бот-сетей, использующих fast-flux DNS, чтобы избежать обнаружения. Я видел сообщения о том, что игнорирование коротких TTL и кэширование в течение более длительного времени было одним из подходов, используемых для работы с этими серверами.

Вы также должны иметь дело с отрицательным кэшированием. Bind 9 использует минимальный TTL в качестве отрицательного периода кэширования. (В вашем случае это, кажется, 10 ч 40, что намного дольше, чем ваш положительный TTL.) Для динамического сервиса вы, вероятно, хотите, чтобы они были такими же.

Я ожидаю, что ваши клиенты разделятся на три класса (у которых могут быть разные потребности):

• Пользователи с довольно стабильными IP-адресами и общедоступные службы используют динамические IP-адреса, что приводит к относительно частым запросам DNS.
• Пользователи с достаточно стабильными IP-адресами, которые время от времени получают удаленный доступ к серверам.
• Дорожные воины, которые часто отключаются, но хотят быть доступными при подключении.

Определить, какие типы пользователей у вас есть, можно с помощью моих контрольных запросов и обновлений вашего DNS. Для определения такого рода данных потребуется время. При определении TTL важно определить, как долго после последнего запроса происходит обновление. Изучение этого значения с течением времени может помочь определить разумный TTL. Изучение частоты запросов и распределения IP-адресов источника в зависимости от частоты обновления также может быть полезным. Это данные, которые вы можете использовать для настройки ваших значений TTL с течением времени.