Card 08/ 09
Practice: Reading dig Output
One dig answer: name the record type, the TTL, the server that answered and whether it was cached.
dig sends a DNS query and prints the full answer, which makes it the standard tool for seeing what a resolver returns. A developer runs it for an API's name. The output is illustrative, with documentation addresses.
dig api.example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41520
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;api.example.com. IN A
;; ANSWER SECTION:
api.example.com. 245 IN CNAME lb.example.net.
lb.example.net. 37 IN A 203.0.113.7
;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)Answer four questions:
- What record types are in the answer, and which address will the client connect to?
- For how many more seconds may the client cache that address?
- Which server answered, and over which transport?
- Did the answer come from a cache? Give two signs.
Show the answers
- A CNAME, then an A record. api.example.com is an alias for lb.example.net, whose A record gives 203.0.113.7, the address the client connects to.
- 37 seconds. The address comes from the A record, so its TTL is the one that matters, not the CNAME's 245. Reading the first TTL is the common mistake.
- 192.168.1.1, over UDP, port 53: a home router acting as the recursive resolver, or forwarding to one.
- Yes. The query took 1 millisecond, far too fast to walk the hierarchy, and the TTLs are odd numbers below what anyone would set, because they have been counting down in the cache. The flags also lack
aa, so no authoritative server answered directly.
← → move through sections and cards