DNS TTL recomendado

24

Eu sei que poderia ser muito diferente com base na situação, mas para hospedar um site sem planos de mover o servidor de hospedagem, qual é um bom TTL para definir no registro DNS?

domain-name-system web-hosting ttl Brian Fisher
fonte

Respostas:

20

Costumo deixá-lo no padrão do Slicehost, 86.400 segundos (1 dia). Eu diminuo para 10 minutos quando tenho uma movimentação pendente e espero um dia ou dois.

edit: Hoje em dia (2016), eu tendem a mantê-lo baixo - ~ 5 minutos.

ceejayoz
fonte
Isso é muita diferença! Seria útil se a resposta incluísse o raciocínio por trás da mudança para um TTL muito mais baixo.
Anthony G - justice for Monica
3
@AnthonyGeoghegan Os servidores modernos podem lidar com solicitações muito mais frequentes, e agora que estou em servidores de nomes altamente confiáveis ​​(AWS Route 53), prefiro ter a flexibilidade de poder alterar o DNS a qualquer momento.
precisa
12

Os padrões (escritos há muito tempo em 1987) sugerem 86.400 segundos (1 dia) como o TTL padrão mínimo.

É importante que os TTLs sejam configurados com valores apropriados. O TTL é o tempo (em segundos) em que um resolvedor usará os dados obtidos do seu servidor antes de perguntar novamente ao servidor. Se você definir o valor muito baixo, seu servidor será carregado com muitas solicitações repetidas. Se você definir um valor muito alto, as informações alteradas não serão distribuídas em um período de tempo razoável. Se você deixar o campo TTL em branco, o padrão será o especificado no registro SOA da zona.

A maioria das informações do host não muda muito durante longos períodos de tempo. Uma boa maneira de configurar seus TTLs seria defini-los com um valor alto e depois abaixá-lo se você souber que uma mudança ocorrerá em breve. Você pode definir a maioria dos TTLs para qualquer lugar entre um dia (86400) e uma semana (604800). Então, se você souber que alguns dados serão alterados em um futuro próximo, defina o TTL para esse RR para um valor mais baixo (de uma hora a um dia) até que a alteração ocorra e, em seguida, volte ao seu valor anterior.

Além disso, todos os RRs com o mesmo nome, classe e tipo devem ter o mesmo valor TTL.

Consulte RFC 1033: http://tools.ietf.org/html/rfc1033

A RFC 1912 (de 1996) sugere que 3 dias podem ser mais apropriados para SOAregistros.

http://www.ietf.org/rfc/rfc1912.txt

dmourati
fonte
4
Eu imagino que o tráfego DNS de baixos TTLs seja um problema significativamente maior em 1987 e 1996 do que em 2011/2012.
precisa
6
Os dois padrões citados referem-se apenas ao campo "Mínimo" do registro SOA, que não é mais usado para determinar o TTL padrão ou mínimo de qualquer maneira, como era planejado quando esses padrões foram gravados. As melhores práticas de DNS escritas há 27 e 18 anos foram escritas quando o DNS - de fato a Internet - era uma fera diferente. Atualmente, 300 segundos (5 minutos) é um TTL bastante comum para os principais registros A / AAAA, embora seja útil apenas quando for necessário failover rápido, caso contrário, 6 horas ou mais seria mais apropriado. Os registros NS e os registros A / AAAA para os endereços NS geralmente são de 1 dia ou mais.
thomasrutter
6
Estou atrasado para comentar sobre isso, mas deve-se notar que é inadequado referir-se a qualquer uma dessas RFCs como "padrões". ( RFC 1796 ) Estou observando isso para que os leitores de hoje não se afastem dessas perguntas e respostas com o entendimento errado.
Andrew B
7

Percebi que está ficando mais moderno ter TTLs mais curtos para poder responder em emergências (principalmente em ambientes de DNS HA) mais rapidamente.

SuperBOB
fonte
1
Sim. O CloudFlare padroniza os TTLs de todos os clientes para 300 segundos (5 minutos), o que é muito curto, mas eles obviamente veem benefícios.
Simon East
3

Eu deixaria no padrão definido pelo seu host, a menos que seja ridiculamente alto ou baixo por algum motivo. Então, se você quiser mover, reduza para 20 minutos mais ou menos alguns dias antes de planejar a mudança.

squillman
fonte
2

4 horas devem estar bem, proporcionando um equilíbrio aceitável. É o que eu uso na maioria das zonas.

Mihai Limbăşan
fonte
4
Provavelmente é muito curto.
Dmourati 17/05/11
5
@dmourati: É 2011. Para a grande maioria dos servidores DNS pequenos (ou seja, com menos de 1000 zonas) e para todo e qualquer cliente, os requisitos adicionais de carga e largura de banda da CPU são absolutamente desprezíveis. Obviamente, se seus servidores DNS ficarem inativos por mais de 4 horas, você estará SOL, mas se isso for importante e você não puder fornecer um serviço DNS confiável, não será possível hospedar seu serviço DNS em uma base tão precária em primeiro lugar. ..
Mihai Limbăşan
3
Quando um usuário faz uma pergunta que é respondida diretamente em uma RFC, você a encaminha para a RFC, independentemente do ano em que está.
precisa saber é o seguinte
@dmourati Isso é prescrito em uma RFC?
Joó Ádám
Sim, veja minha resposta acima.
Dmourati
2

(nota: esta postagem se aplica ao TTL nos registros A / AAAA individuais, alguns outros tipos de registros podem ter TTLs mais longos porque não representam pontos únicos de falha da mesma maneira).

Você realmente precisa pensar sobre isso em termos de seus planos de recuperação de desastres. Não se trata de quando você pretende mover o site (para movimentos intencionais, você pode reduzir o TTL na corrida para o movimento). É quando seu host desaparece da Internet ou o expulsa por uma violação de TOS ou o expulsa porque eles não conseguem lidar com o DDOS que apareceu no seu caminho.

Se você não se importa com o site ficar inativo por um dia ou mais nessas circunstâncias, vá em frente e deixe o TTL como padrão de um dia. Se você tiver espaço de endereço PI e trânsito de BGP em vários locais de vários provedores e pretender lidar com a recuperação de desastres no nível de BGP, vá em frente e deixe-o no dia padrão. Por outro lado, se você estiver usando o DNS como seu mecanismo de divisão de sua taxa em um site de failover, desejará um TTL muito mais curto, 5 minuites é um valor bastante comum.

Peter Green
fonte