Оптимизация значений 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.

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

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

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

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

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

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