I'm wondering if there is a way to query a DNS server and bypass caching (with dig). Often I change a zone on the DNS server and I want to check if it resolves correctly from my workstation. But since the server caches resolved requests, I often get the old ones. Restarting or -loading the server is not really something nice.
You can use the
@syntax to look up the domain from a particular server. If the DNS server is authoritative for that domain, the response will not be a cached result.You can find the authoritative servers by asking for the
NSrecords for a domain:There is no mechanism in the DNS protocol to force a nameserver to respond without using its cache. Dig itself isn't a nameserver, it is simply a tool that passes your query on to whichever nameservers you have configured, using standard DNS requests. DNS does include a way to tell a server not to use recursion, but this isn't what you want. That's only useful when you want to directly query an authoritative nameserver.
If you wanted to stop a nameserver from responding from its cache, you'd only be able to do that by altering the configuration on the nameserver, but if you don't control the nameserver, this is impossible.
You can, however, get dig to bypass the configured nameservers, and perform its own recursive request which goes back to the root servers. To do this, use the
+traceoption.In practice since this will only query the authoritative servers rather than your local caching resolver, the result won't be stale even if those servers employ internal caching. The added benefit of using
+traceis that you get to see all of the separate requests made along the path.Something important to note here, which I notice many people don't ever include when talking about
+traceis that using+tracemeans the dig client will do the trace, not the DNS server specified in your config (/etc/resolv.conf). So, in other words, your dig client will work like a recursive DNS server would, should you ask it. But - importantly, you haven't got a cache.More detail - so if you've already asked for an
mxrecord usingdig -t mx example.comand your /etc/resolv.conf is 8.8.8.8 then doing anything inside the TTL of the zone will return the cached result. In a way, if you're looking for something about your own zone and how Google sees it, you've sort of poisoned your DNS results with Google for the TTL of your Zone. Not bad if you have a short TTL, somewhat rubbish if you have a 1hr one.So, whilst
+tracewill help you to see what WOULD be seen if you were asking Google for the FIRST time and it had no cached entry, it may give you a false idea that Google will be telling everyone the same as what your+traceresult was, which it won't if you'd asked previously and have a long TTL, as it'll serve that from cache until the TTL expires - THEN it'll serve the same as what your+tracerevealed.Can't have too much detail IMO.
This bash will dig example.com's DNS entries from it's first listed name server:
Here's the same as an alias for a .zshrc (and probably .bashrc):
Here's the output for /.:
This solution is complicated enough to be impractical to remember, but simple enough for the problem to not be fixed.
digisn't my specialty - improvements welcome :-)Thanks to this solutions I am able to check propagation of DNS TXT records which I need to add to AZURE DNS Zone, for LetsEncrypt certificates. Here is my dig command: