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

Я наконец-то получил свою собственную DYNDNS, но я ищу несколько советов по ее оптимизации.

Изменить: В основном я получил домен в регистраторе, который я указываю на свои собственные серверы имен, где я храню свои собственные записи. я использую nsupdate обновить записи. Я хочу, чтобы пользователи могли зарегистрироваться, получить поддомен, который они могут указывать на устройство, которое получило динамический IP-адрес, что делает его "статическим".

Пример динамического обновления http://ip.seveas.net/dnsgraph/png/client1.epnddns.com/?skip_.=on&show_A=Show

По сути, я хочу добиться самого быстрого решения, если я могу это так назвать. Означает наименьшее количество времени, которое пользователь должен ждать после того, как он / она обновит свой поддомен, пока он фактически не сможет использовать его / разрешить. Не останавливая сервер, подумайте +1000 пользователей. Если это имеет смысл?

Поэтому я задаюсь вопросом о значениях TTL для SOA, моих серверов имен и о том, что давать динамически создаваемые поддомены, которые пользователи могут обновлять довольно часто.

Другой вопрос, в примере о с client1. Похоже, что он хорошо разрешается на других устройствах или для других пользователей, но из моего дома с IP-адресом, который я также использовал для обновления записи, кажется довольно случайным, подключается он или нет. Может ли это быть что-то необычное в моей настройке или это может быть связано с тем, что я обновил записи с моего домашнего IP?

мои первые значения nameserver

$ORIGIN .
$TTL 38400      ; 10 hours 40 minutes
mydomain.com             IN SOA  ns3.mydomain.com. admin.mydomain.com. (
                                2880848856 ; serial
                                28800      ; refresh (8 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                38400      ; minimum (10 hours 40 minutes)
                                )
                        NS      ns3.mydomain.com.
                        NS      ns4.mydomain.com.
                        A       66.33.x.x
$ORIGIN mydomain.com.
$TTL 10 ; 10 seconds
client1                 A       75.119.x.x
$TTL 38400      ; 10 hours 40 minutes
ns3                     A       64.111.x.x
ns4                     A       67.205.x.x
www                     A       66.33.x.x

мои вторые значения серверов имен

$ORIGIN .
$TTL 38400      ; 10 hours 40 minutes
mydomain.com             IN SOA  ns4.mydomain.com. admin.mydomain.com. (
                                2006071806 ; serial
                                28800      ; refresh (8 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                38400      ; minimum (10 hours 40 minutes)
                                )
                        NS      ns3.mydomain.com.
                        NS      ns4.mydomain.com.
                        A       66.33.x.x
$ORIGIN mydomain.com.
$TTL 10 ; 10 seconds
client1                 A       75.119.x.x
$TTL 38400      ; 10 hours 40 minutes
ns3                     A       64.111.x.x
ns4                     A       67.205.x.x
www                     A       66.33.x.x

Кроме этого, есть ли другие способы его оптимизации?

Заранее спасибо за любые идеи и советы!

2 ответа

Вы написали:

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

Не могли бы вы немного прояснить, что вы пытаетесь достичь, регулируя значение 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 с течением времени.

Другие вопросы по тегам