Como entender os valores de TTL na saída do comando dig?

3

Estou lendo sobre como o DNS funciona em geral. A partir da entrada wiki do TTL , eu entendo que TTL (Time to Live) ocorre no domínio Sistema de nomes ( DNS ), onde eles são definidos por um servidor de nomes autoritativo para um registro de recurso específico. Quando um servidor de nomes de armazenamento em cache (recursivo) consulta o servidor de nomes autoritativo para um registro de recurso, ele armazenará em cache esse registro pelo tempo (em segundos) especificado pelo TTL.

Agora, eu precisava usar as ferramentas Linux CLI ( dig ) para descobrir qual é o TTL real definido no servidor de nomes autoritativo e, assim, usei meu comando como abaixo.

dig +trace +nocmd +noall +answer +ttlid a www.stackoverflow.com

#I have omitted the root name server output for better readability. 

www.stackoverflow.com.  300 IN  CNAME   stackoverflow.com.
stackoverflow.com.  300 IN  A   198.252.206.140
;; Received 80 bytes from 173.245.59.4#53(cf-dns02.stackoverflow.com) in 9 ms

Como pude ver no registro A de stackoverflow.com. , o valor TTL no servidor de nomes autoritativo é 300.

Então, isso significa que, se eu pesquisar por stackoverflow.com após 300 segundos ou 5 minutos, o endereço IP de stackoverflow.com será resolvido totalmente do domínio .com ?

    
por Ramesh 09.12.2014 / 07:16

1 resposta

3

Não; não todo o caminho do domínio .com (na verdade, eu acho que você quis dizer a partir do domínio raiz?).

Os registros NS para stackoverflow.com têm um TTL de 172800, portanto, eles são armazenados em cache muito mais do que os 300 segundos do registro www.stackoverflow.com CNAME e o registro stackoverflow.com A. Então, depois que os registros CNAME e A expirarem, os registros NS provavelmente ainda serão armazenados em cache e, portanto, esses servidores de nomes poderão ser questionados sobre www.stackoverflow.com (e, em seguida, stackoverflow.com ).

BTW eu não teria dado tanto www.stackoverflow.com quanto stackoverflow.com de TTL de apenas 300, isso significa duas vezes mais solicitações de DNS sem qualquer vantagem IMHO imediatamente evidente.

    
por 09.12.2014 / 09:04

Tags