Yes, the number there is the number of seconds left until that record expires (providing we're not querying the authoritative nameserver). Obviously with a CNAME there's a level of redirection, so the TTL for the A record it points to in this case may be important as well.
If you wait a couple of seconds and run dig again on your local nameserver, you should see that TTL number decrease by the number of seconds you waited (approximately). When it hits 0, it'll refresh or if your nameserver refreshes the zone for some reason.
As mentioned above, there is a difference between dig being run against a nameserver with a cached entry and the nameserver that is authoritative for that entry.
(in the examples I use below I use the +noauthority
+noquestion
& +nostats
flags just to keep the output terse).
Note the difference between the following queries:
$ dig +noauthority +noquestion +nostats stackoverflow.com @ns2.p19.dynect.net.
; <<>> DiG 9.7.0-P1 <<>> +noauthority +noquestion +nostats stackoverflow.com @ns2.p19.dynect.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50066
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; ANSWER SECTION:
stackoverflow.com. 432000 IN A 69.59.196.211
So in the above query, we're querying a nameserver that is authoritative for stackoverflow.com. If you notice the flags
section, pay special attention to the aa flag which denotes this is an authoritative answer (i.e. not cached).
$ dig +noauthority +noquestion +noadditional +nostats stackoverflow.com
; <<>> DiG 9.7.0-P1 <<>> +noauthority +noquestion +noadditional +nostats stackoverflow.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43514
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
stackoverflow.com. 246696 IN A 69.59.196.211
In the above query, we don't have an aa flag, and the TTL will keep decreasing as we query and query. This is essentially the counter I was talking about previously.
Why does it happen?
Some host in path filtering you traceroute
Is it any difference between the TTL value showed in ping and the TTL value of tracert ?!
no difference(ping ttl=55, tracepath ttl=back=55)... no host filtering trace
ping ya.ru
PING ya.ru (87.250.250.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (87.250.250.3): icmp_seq=1 ttl=55 time=36.6 ms
tracepath ya.ru
....................
8: l3-s550-s450.yandex.net (213.180.213.23) 97.070ms
9: l3-s650-s550.yandex.net (213.180.213.29) 97.992ms
10: www.yandex.ru (77.88.21.3) 91.306ms reached
Resume: pmtu 1500 hops 10 back 55
Then when I ping google.com the returned TTL value is 45, and I assume it means that (128 - 45) / 2 hops are existed in my way to google.
No. Path = 64(default google.com ttl) - 45(ping ttl) = 19 hops
Best Answer
Packets sent to localhost don't go over any hops so the ttl shown will be the starting value.
Windows 10
OpenWrt 15.05