Querying an authoritative nameserver directly helps distinguish a stored DNS configuration problem from an old resolver cache. Use the actual servers published for the domain, and test every delegated server before concluding that the zone is consistent.
IN THIS ARTICLE
01 Prepare the exact query
On a system with dig available, replace 192.0.2.53 below with the real authoritative server address and replace the documentation domain with your own. The example address is not a working DNS service.
dig @192.0.2.53 example.com SOA +norecurse
dig @192.0.2.53 www.example.com A +norecurse
dig @192.0.2.53 example.com MX +norecurseThe @ target selects the server. +norecurse asks it to answer without performing a recursive lookup for you. Keep the full response while investigating so you can see status, flags, answer and authority sections.
02 Read and compare the result
- Confirm that the response came from the intended server address.
- Look for the
aaauthoritative-answer flag for an answer the server should authoritatively provide. - Check the exact owner name, type, value and TTL. An A answer does not prove that AAAA or MX is also correct.
- Repeat against every delegated authoritative server and compare the relevant records.
- Compare these results with the normal recursive lookup from the affected network.
What does a timeout or REFUSED answer mean?
A timeout can indicate reachability, firewall or server failure; it is not evidence of an empty zone. A refusal can mean the queried service will not answer that request. Verify the target, delegation and zone assignment before changing the DNS records.
Where authorised network access permits it, repeat a failed query with +tcp to help distinguish transport behaviour. If one delegated server differs or fails, provide the server address and complete response to the DNS operator. Intermittent success can occur when only part of the authoritative set is working.
Does an authoritative answer prove DNSSEC validation?
No. The authoritative flag identifies the responding role; it is not a cryptographic validation result. Check the DNSSEC chain with a validating resolver or appropriate diagnostic tool separately. A correct direct answer can coexist with a public validation failure.