dig +trace command
dig @ip 域名 类型 +trace
work process
Take dig pbc.gov.cn +trace as an example.
-
What users see
-
The results seen by wireshark captured packets (only the query part is displayed, and the response is the response of the query destination to the source address)
| step | source | purpose | Inquire |
|---|---|---|---|
| 1 | Native | ip specified in @ip | .NS |
| 2 | Native | Local DNS | . NS A (may try to query multiple NS A) |
| 3 | Native | root | NS of pbc.gov.cn |
| 4 | Native | Local DNS | A of the NS of gov.cn (may try to query the A of multiple NSs) |
| 5 | Native | NS of gov.cn | NS of pbc.gov.cn |
| 6 | Native | Local DNS | NS A of pbc.gov.cn (may try to query A of multiple NS) |
| 7 | Native | NS of pbc.gov.cn | NS of pbc.gov.cn |
Operational meaning
After adding trace to the dig command:
- Need to iterate the query from the root
- The iterative work of querying NS is done by this machine, not by the recursive server.
After adding trace to dig, I actually want to know the complete domain name iterative query process. Since the machine cannot get the iterative query message of the recursive server, it iterates the search process by itself. Each query of NS's A must be done through the local DNS, which may be because the machine cannot parse the A record corresponding to the NS in the ADDITIONAL field from the NS message obtained recursively. When querying the A records of the NS, the A records of multiple NSs may be queried. The reason is not clear.
references
[CSDN] A detailed analysis of the request of each message of dig +trace through wireshark capture