Ttyjfyk

In name resolution (current version of bind), what happens when a recursive answer reaches ttl 0 on the return trip?

Do you mix up IP and DNS Time-To-Live's?

An IP packet's TTL...

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.

The TTL of DNS records

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.

Thus a DNS record's TTL never reaches zero; whereas the IP packet that is used to request a DNS record might reach TTL=0, what would result in the sender receiving the mentioned ICMP error.

The TTL value is the time (usually in secs) a cached dns entry is kept in cache before it is refreshed. So once the TTL value reaches zero, it will go query the authoritative nameserver again for an up-to-date dns entry.

You can see this refreshing of dns entries with the dig command.
Here's an example of dig querying the google.com domain (I chose this domain because of its small TTL value so I don't need to wait so long for the dns entry to be refreshed):

$ 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

Now check the Query time again...

$ 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

Query time is smaller because the locally cached value of google.com is being returned.

Now let's wait for the TTL value to decrease to 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

almost there...

$ 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

Now the cached dns value is refreshed; TTL value starts counting down again...

$ 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