-1

When I ran ping google.com, I get a ttl value of 55:

64 bytes from 173.194.127.103: icmp_seq=68 ttl=55 time=16.4 ms

When I ran dig google.com @ns1.google.com., it get a TTL value of 300.

google.com.     300 IN  A   173.194.127.34

Why do I get two different values for TTL, and which one is relevant in what situation?

dayuloli
  • 1,293
  • However, unlike the answer given there, when I run dig google.com, the TTL is different every time, and does not gradually decrease. Plus the question is more about all the other different values e.g. from ping – dayuloli Jan 21 '15 at 14:04
  • Do you have a non-google example? It may be a fruitless endeavor to speculate on what the google corp engineers are up to.. – Daniel Widrick Jan 21 '15 at 14:06
  • Ar! I tried dig xkcd.com, and the values are 'more stable' - 1195, 1200, 1195, 1097, 216, 1084. The AUTHORITY SECTION and ADDITIONAL SECTION fluctuate a lot too. – dayuloli Jan 21 '15 at 14:10
  • This question was really two questions. The first one was answered - the other one is here. Thanks guys for your help. – dayuloli Jan 21 '15 at 14:31
  • 1
    @dayuloli Related answers regarding fluctuations in ADDITIONAL and AUTHORITY. – Andrew B Jan 21 '15 at 16:00
  • 1
    I've reopened this as the edited form is not at all a duplicate of http://serverfault.com/questions/179630/how-can-i-see-time-to-live-ttl-for-a-dns-record – Sven Jan 22 '15 at 01:21
  • 2
    This is a legitimate question. Not sure why all the downvotes. Also, re ping TTLs: http://www.map.meteoswiss.ch/map-doc/ftp-probleme.htm – dmourati Jan 22 '15 at 04:09

2 Answers2

5

The TTL with ping has an entirely different meaning then for DNS.

For DNS, it means how long a record may be cached before it is to be considered too old. The value for ping means how many hops the packet may take over different networks before it will be thrown away. Every hop along the path to the target will reduce this value by 1 and if there are too many hops, the packet will be dropped. This is meant to prevent never ending loops for packets in case of configuration errors.

And I agree that a behemoth like Google that has to go to extraordinarily lengths and uses every trick available to be able to answer as fast as they do isn't a good example to look into this matter.

Sven
  • 99,533
  • 15
  • 182
  • 228
0

Additional context on ping TTL from the manpage.

TTL DETAILS
       The  TTL  value  of  an  IP  packet represents the maximum number of IP
       routers that the packet can go through before being  thrown  away.   In
       current  practice  you can expect each router in the Internet to decre-
       ment the TTL field by exactly one.

       The TCP/IP specification states that the  TTL  field  for  TCP  packets
       should  be set to 60, but many systems use smaller values (4.3 BSD uses
       30, 4.2 used 15).

       The maximum possible value of this field is 255, and most Unix  systems
       set the TTL field of ICMP ECHO_REQUEST packets to 255.  This is why you
       will find you can ‘‘ping’’ some hosts, but not  reach  them  with  tel-
       net(1) or ftp(1).

       In  normal  operation  ping  prints  the  ttl  value from the packet it
       receives.  When a remote system receives a ping packet, it can  do  one
       of three things with the TTL field in its response:

       · Not  change  it;  this  is  what Berkeley Unix systems did before the
         4.3BSD Tahoe release. In this case the  TTL  value  in  the  received
         packet  will  be  255  minus  the number of routers in the round-trip
         path.

       · Set it to 255; this is what current Berkeley  Unix  systems  do.   In
         this  case the TTL value in the received packet will be 255 minus the
         number of routers in the path from the remote system to  the  pinging
         host.

       · Set it to some other value. Some machines use the same value for ICMP
         packets that they use for TCP packets, for example either 30  or  60.
         Others may use completely wild values.
dmourati
  • 25,870