Authoritative and recursive DNS answer different questions

Authoritative and recursive DNS answer different questions begins with a practical question: how can a reader inspect resolver path and authority without confusing a provider promise with a field observation?

Method for this question

Name the server before interpreting an answer. The authoritative server is responsible for the zone data; a recursive resolver asks on behalf of a client and may return a cached answer, a referral or a negative result. Start by finding the delegation at the parent, query an authoritative nameserver directly, then query the resolver used by the affected user. Save the status, answer section, authority section, TTL and timestamp. Running the same sequence from a second network helps distinguish a zone problem from a local resolver, VPN or captive-network problem.

What to record

• which server was queried
• whether the answer was authoritative
• TTL and cache age
• parent delegation versus zone data

A useful diagnostic chain is parent delegation, authoritative answer, recursive answer and application behavior. If the parent points at nameservers that do not serve the zone, editing records in a dashboard will not help. If authority is correct but a resolver returns an older value, compare TTL and negative-cache behavior before calling it propagation. If DNS answers match but HTTPS fails, move to certificate, routing or origin checks. The distinction matters because each layer has a different owner and a different repair. Keep the exact query command or tool URL beside the result.

A realistic failure pattern

During a migration, the new provider supplies records in its dashboard but the domain still delegates to the old provider. The old authoritative server returns the old A record, while a resolver that cached it continues doing the same. A direct query to the new provider may look perfect and still be irrelevant to public traffic. The operator should update delegation at the registrar, verify both parent and authoritative answers, then watch recursive answers from the target audience. Only after those agree should the web request be used to confirm the application layer.

Errors and boundaries

The word propagation hides too much. Resolvers cache successful answers, negative answers and referrals under different rules, and a local operating system may add another cache. A public DNS checker is useful for comparison but is not itself authoritative. Do not edit several providers at once to make answers converge; that destroys the evidence trail. IANA explains the root and delegation context, while the zone owner and resolver operators control the next layers. A recursive answer is a view, not proof of the zone’s current contents.

What this does not prove

Propagation is not one universal timer. The resolver, TTL, negative caching and delegation all affect what a reader sees.

The Domain Host USA desk uses the documented fact, field observation, provider statement and editorial recommendation labels so readers can see what kind of sentence they are reading.

This note connects to the Infrastructure Field Desk, where the sample method and dated observations remain visible. Continue through DNS & Internet for related decisions rather than treating one check as a complete review.