O que acontece em uma consulta recursiva de dns, se ttl = 0?

Question

Na resolução de nomes (versão atual do bind), o que acontece quando uma resposta recursiva atinge ttl 0 na viagem de retorno?

    

Answer 1

Você mistura tempo de vida de IP e DNS?

Um TTL do pacote IP ...

is set by the sender of the datagram, and reduced by every router on the route to its destination. If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to the sender.

O TTL dos registros de DNS

are set by an authoritative name server for a particular resource record. When a caching (recursive) nameserver queries the authoritative nameserver for a resource record, it will cache that record for the time (in seconds) specified by the TTL.

Assim, o TTL de um registro DNS nunca chega a zero; enquanto o pacote IP usado para solicitar um registro DNS pode atingir TTL=0 , o que resultaria no envio do erro ICMP mencionado pelo remetente.

    

Answer 2

O valor de TTL é o tempo (normalmente em segundos) que uma entrada de cache em cache é mantida em cache antes de ser atualizada. Assim, quando o valor TTL chegar a zero, ele consultará o servidor de nomes autoritativo novamente para uma entrada de DNS atualizada.

Você pode ver essa atualização de entradas do DNS com o comando dig. Aqui está um exemplo de digitação no domínio google.com (escolhi esse domínio por causa de seu pequeno valor de TTL, portanto, não preciso esperar tanto tempo para a entrada do DNS ser atualizada):

$ dig google.com

; <<>> DiG 9.8.1-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39327
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     154 IN  A   74.125.237.33  <== '154 is the  TTL value'
... (ANSWERS TRUNCATED)

;; Query time: 16 msec   <== notice that the query took 16ms to complete
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:04:56 2012
;; MSG SIZE  rcvd: 204

Agora, verifique novamente o tempo de consulta ...

$ dig google.com

... (HEADER TRUNCATED)

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     103 IN  A   74.125.237.35  <== TTL value gradually decreases over time
... (ANSWERS TRUNCATED)

;; Query time: 2 msec <== query time is much smaller!
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:05:48 2012
;; MSG SIZE  rcvd: 204

O tempo de consulta é menor porque o valor do google.com em cache local está sendo retornado.

Agora vamos esperar que o valor TTL diminua para zero ...

$ dig google.com @localhost

... (HEADER TRUNCATED)

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     5   IN  A   74.125.237.34
... (ANSWERS TRUNCATED)

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:07:26 2012
;; MSG SIZE  rcvd: 204

quase lá ...

$ dig google.com @localhost

... (HEADER TRUNCATED)

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     1   IN  A   74.125.237.39
... (ANSWERS TRUNCATED)

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:07:30 2012
;; MSG SIZE  rcvd: 204

Agora, o valor do DNS armazenado em cache é atualizado; O valor TTL começa a contagem regressiva novamente ...

$ dig google.com @localhost

... (HEADER TRUNCATED)

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     291 IN  A   74.125.237.131
... (ANSWERS TRUNCATED)

;; Query time: 16 msec <== Notice the longer Query time again.
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 17 21:07:32 2012
;; MSG SIZE  rcvd: 204

Espero que isso ajude você a entender um pouco melhor ...