Otimizando valores TTL para o serviço DYNDNS

Question

Eu finalmente consegui meu próprio DYNDNS trabalhando, mas estou procurando alguns conselhos para otimizá-lo.

Editar: Basicamente, eu tenho um domínio em um registrador que eu aponto para os meus próprios servidores de nomes, onde eu mantenho meus próprios registros. Estou usando nsupdate para atualizar registros. Eu quero que os usuários possam se registrar, obter um subdomínio, eles podem apontar para um dispositivo que tem um IP dinâmico, tornando-o 'estático'.

Um exemplo de uma atualização dinâmica link

Basiclly eu quero alcançar a resolução mais rápida, se é que posso chamá-lo assim. Significa a menor quantidade de tempo que um usuário tem que esperar após atualizar seu subdomínio até que possa realmente usá-lo / resolvê-lo. Sem interromper o servidor, pense em 1 000 usuários. Se isso faz sentido?

Estou pensando sobre os valores de TTL para SOA, meus nameservers e o que fornecer subdomínios criados dinamicamente e que os usuários podem atualizar com bastante frequência.

Outra questão é, no exemplo about with client1. Parece resolver bem em outros dispositivos ou para outros usuários, mas da minha casa com o IP que eu também usei para atualizar o registro, parece bastante aleatório se ele se conecta ou não. Poderia ser algo funky na minha configuração ou pode ter algo a ver com isso eu atualizei os registros do meu IP de casa?

meus primeiros valores de 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

meus valores de segundo nameservers

$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

Além disso, existem outras maneiras de otimizá-lo?

Agradecemos antecipadamente por qualquer informação ou conselho dado!

    

Answer 1

Você escreveu:

I was wondering if there was someone out there who could give me some pointers on optimizing it to get the fastest resolves without pushing the service too much.

Você poderia ser um pouco mais claro sobre o que você está tentando realizar ajustando seu valor de TTL?

Como presumo que você saiba, o TTL controla (ou deve controlar - nem todos os nameserver realmente o honram adequadamente) por quanto tempo os registros de recursos podem permanecer no cache de um servidor de nomes não autoritativo.

Os clientes que estão tentando resolver consultas para seus registros ("talvez" seja uma maneira melhor de colocá-los) receberão uma resolução mais rápida se puderem obter uma resposta do cache de seu resolvedor recursivo local. Portanto, nesse sentido, um TTL mais longo permite que outros servidores de nomes armazenem em cache seus dados RR por mais tempo, gerando uma maior probabilidade de que os clientes que consultam possam ter suas consultas satisfeitas a partir do cache. Nesse sentido, o TTL alto tende a melhorar a velocidade de resolução de consultas do cliente.

No entanto, você precisa equilibrar isso com o problema de servidores não-autoritativos armazenando dados incorretos em cache. Quando seus dados são alterados (por exemplo, porque você mudou para um endereço IP diferente ou alterou o destino de um registro), outros servidores de nomes têm permissão para armazenar em cache os dados antigos para até TTL segundos. Portanto, se você estiver alterando seus dados com frequência (por exemplo, mudando para novos endereços IP com frequência ou alterando o conteúdo de sua zona), você desejará reduzir seu TTL.

Como especificado no momento, sua pergunta não fornece nenhuma orientação sobre a rapidez com que seus dados são alterados, por isso não é possível aconselhá-lo mais especificamente sobre quais valores de TTL são apropriados. Eles dependerão muito do seu padrão de uso.

    

Answer 2

Espero que isso seja para um caso de volume relativamente baixo. Servidores que precisam de grandes volumes de pesquisas de DNS confiáveis pertencem a um endereço IP estático. Se assim for, o ajuste dos TTLs não deve ser tão importante.

É difícil dar bons conselhos com informações parciais. As respostas a seguir funcionaram para mim. Como tenho apenas informações limitadas, a resposta pode não ser apropriada no seu caso.

Ao escolher um TTL para este caso, eu verificaria o TTL na origem do endereço IP. Se você estiver usando o DHCP com uma concessão de mais de um minuto ou dois, um TTL de 10 segundos poderá ser extremo.

Se você estiver fornecendo um serviço DYNDNS interno para clientes DHCP, uma metade TTL ou um quarto do tempo de concessão. O seu TTL para um serviço voltado externamente recebendo seu endereço dinamicamente, você pode querer um TTL mais curto.

Os fatores a serem considerados serão onde os dados serão armazenados em cache, com que frequência as alterações de endereço ocorrerão e o quanto é importante que não haja descontinuidade do serviço. Você também deve considerar onde as conexões mal direcionadas podem aterrissar. Internos para a organização ou endereços mortos são provavelmente menos preocupantes do que um servidor na Internet que você não tem controle.

EDIT :: Qualquer TTL que você especificar alguns servidores DNS irá ignorá-lo um cache para o seu próprio TTL. Eu acredito que isso é mais provável de ocorrer com TTLs mais curtos. Há alguns anos houve uma onda de botnets usando o DNS fast-flow para tentar evitar a detecção. Eu vi relatórios que ignoram TTLs curtos e cache por um longo tempo foi uma abordagem usada para lidar com esses servidores.

Você também precisa lidar com o cache negativo. A ligação 9 usa o TTL mínimo como o período de cache negativo. (No seu caso, isso parece ser 10h40, o que é muito mais longo do que o seu TTL positivo.) Para um serviço dinâmico, você provavelmente quer que eles sejam iguais.

Espero que seus clientes se enquadrem em três turmas (que podem ter necessidades diferentes):

• Usuários com endereços IP bastante estáveis e executando serviços públicos em IPs dinâmicos, resultando em consultas DNS relativamente frequentes.
• Usuários com endereços IP bastante estáveis, que ocasionalmente acessam os servidores remotamente.
• Road warriors que são frequentemente desconectados, mas que desejam estar acessíveis quando conectados.

Determinar quais tipos de usuários você pode fazer minhas consultas de monitoramento e atualizações no seu DNS. Levará tempo para determinar esse tipo de dados. De importância na determinação do TTL é determinar quanto tempo após a última consulta ocorrer uma atualização. Examinar este valor ao longo do tempo pode ajudar a determinar um TTL razoável. O exame da frequência de consulta e da distribuição de IP de origem versus a frequência de atualização também pode ser útil. Estes são dados que você pode usar para ajustar seu (s) valor (es) TTL ao longo do tempo.