1

I traceroute to 104.210.32.76:

Traceroute Starting…

traceroute to 104.210.32.76 (104.210.32.76), 64 hops max, 72 byte packets
 1  10.10.10.1 (10.10.10.1)  25.326 ms  1.344 ms  1.135 ms
 2  100.64.0.1 (100.64.0.1)  3.942 ms  9.469 ms  5.892 ms
 3  * * *
 4  171.208.203.97 (171.208.203.97)  6.452 ms  113.181 ms  15.091 ms
 5  59.43.80.61 (59.43.80.61)  14.810 ms  7.005 ms  7.341 ms
 6  59.43.146.217 (59.43.146.217)  39.508 ms  38.473 ms  46.940 ms
 7  * 59.43.130.158 (59.43.130.158)  34.990 ms  41.833 ms
 8  59.43.187.146 (59.43.187.146)  48.928 ms  50.978 ms  55.455 ms
 9  59.43.183.110 (59.43.183.110)  64.377 ms  39.456 ms  43.075 ms
10  59.43.247.22 (59.43.247.22)  57.411 ms  50.446 ms  60.908 ms
11  210.48.136.74 (210.48.136.74)  44.653 ms  41.837 ms  41.412 ms
12  * * *
13  104.210.32.76 (104.210.32.76)  79.754 ms  53.262 ms  59.980 ms

I have some queries on the logs:

  1. the data list, such as 100.64.0.1 (100.64.0.1), is them all network's gateway? and why there has a parenthesis? the 100.64.0.1 can represent its address, why there still need a parenthesis contains it again?

  2. why the line 7 there is a * and only two time durations? what are the meaning of the three time durations?

  3. I know the * * * means that hop do not permits ping, so, is the line 11's address(210.48.136.74) transmit to the line 13(104.210.32.76) directly?

Improve this question

1 Answer 1

Reset to default
4

1 - By default, traceroute try to perform a reverse DNS lookup and will output the DNS name followed by the IP address in parenthesis.

Many routers IP addresses don't have a PTR record, so the DNS lookup fail and traceroute display the IP address in place of the non-existent DNS name followed by the IP address in parenthesis.

If you use the -n switch, that tell traceroute to not perform the reverse DNS lookup you will have only the IP address displayed.

2 - Also by default, traceroute sent three probes for each TTL value, and display the Round Trip Time of each probe, hence the three "time duration" you see. From the traceroute man page on my MacOS system:

Three probes (changed with -q flag) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe. If the probe answers come from different gateways, the address of each responding system will be printed. If there is no response within a 5 sec. timeout interval (changed with the -w flag), a "*" is printed for that probe.

So for line seven, you received a response from 2 of the 3 probes.

You can use the -q switch to change the number of probe sent and so the number of RTT displayd.

3 - No, there's a router between hop 11 and 13, but the configuration of this router is so that it didn't respond to the traceroute probes.

I recommand you read the man page of traceroute, it contains several examples that help understand how it works and how to interpret the results.

Also please note that traceroute is a useful tool in a network you control where you know the expected result, but running traceroute on the Internet can give weird / unexpected results.

Improve this answer
5
  • Many routers IP addresses do not have ` PTR record`, is it mean the A record, addresses record? is there use A record better?
    – qg_java_17137
    Oct 11, 2018 at 7:47
  • 2
    No, a HOST (A) record resolve a DNS name to an IP address. A Pointer (PTR) record do the opposite: it gives the DNS name associated with an IP address. Most IP address don't have a PTR record, but it is needed for mail servers, for example.
    – JFL
    Oct 11, 2018 at 8:03
  • email servers don;t actually need Pointer addresses, they only need MX addresses. Some Very poor attempts to curtail spam in the late 1990s and early 2000s called for the mail servers to have PTR records IDing them as the domain name that the SMTP server was sending as, but this was never adopted as a standard and was proven to be of little value, so to this day only a few email services continue to follow that practice.
    – Ben Personick
    Oct 11, 2018 at 19:56
  • @BenPersonick It seems it's not mandatory per RFCs but I often saw email rejected because of a Forward-confirmed reverse DNS (FCrDNS) check on the sending IP address. (I.E. there must be a PTR record and the name returned by the PTR record must resolve to the original IP address). I was not referring to a banner check which I never encountered indeed.
    – JFL
    Oct 12, 2018 at 6:17
  • @JFL, I was not talking about banner, where did you get that impression I was? FCrDNS is a poor spam promulgation control, and isn't an actual requirement for Mail. As I said, some mail services still check this but it was never universally required or agreed to, and has been on the decline since the early 2000s as there is no universal need or conformity to this rule, and as a method of maintaining white-lists it is only of small value as an originating email may flow through many mail servers, or from other services as well, so other better methods are the norm instead.
    – Ben Personick
    Oct 12, 2018 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.