Networking Fundamentals Practice Question 5: DNS Caching TTL
Networking Fundamentals · Test 1 · question 5 of 10
An administrator changes the A record for app.example.com to point at a new server. The record's TTL is 86400. An hour later, some users reach the new server but others still reach the old one, and the zone's authoritative name server returns the new address correctly. What is the most likely cause?
Show answer and explanation
Answer:
Most clients don't query the authoritative server directly. They ask a recursive resolver (the ISP's, the company's, or a public one), and the resolver caches each answer. The record's TTL, in seconds, says how long it may be cached before being discarded. 86400 seconds is 24 hours, so any resolver that cached the old address shortly before the change can keep handing it out for up to a day. Users behind resolvers that hadn't cached it get the new address straight away. So B is correct.
The usual fix is to lower the TTL well before a planned change, then raise it again afterwards.
- A is contradicted by the stem: the authoritative server is already returning the new address. - C misreads the TTL. It is a cache lifetime for the record, not an instruction to retry an address. - D is wrong because root servers don't hold a domain's A records. They only refer queries to the top-level domain servers. There is no 24-hour replication step for A records.
Reference: RFC 1034 - Domain Names: Concepts and Facilities, section 3.6