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.

up vote 104 down vote accepted

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.

dig @ns1.example.com example.com

You can find the authoritative servers by asking for the NS records for a domain:

dig example.com NS
  • 2
    Oh okay. Yeah I was familiar with the @ syntax, but haven't had the idea to query the authoritative server instead. Thanks! – Daniel Mar 21 '12 at 17:22
  • 3
    Side note: in cases where you're trying to see what responses a caching server would get, +norecurse is recommended. +recurse is on by default will occasionally change the way a DNS server interprets your question entirely. – Andrew B Mar 1 '13 at 4:37
  • 4
    What if you're waiting for the authoritative servers to change? – guaka Aug 5 '14 at 12:12
  • @KasperSouren Are you talking about the NS records at the authoritative servers or the glue records at the parent? You can find the parent with +trace but beware of caching. Andrew B wrote up a good explanation of how caching can trick you when waiting for nameservers to change. – Ladadadada Aug 7 '14 at 6:46
  • 2
    you can also check on google dns dig @8.8.8.8 example.com. the records appear much faster there. – machineaddict Mar 26 at 10:47

There is no standard, reliable way 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. There is a way to say "don't use recursion", but this is not what you want - it would simply prevent any lookups of domain names on the wider internet.

If you wanted to stop a nameserver from responding from its cache, you'd have to achieve that by altering the configuration on the nameserver, but if you don't control the nameserver, you can't do that.

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 +trace option.

dig example.com +trace

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 +trace is that you get to see all of the separate requests made along the path.

  • 9
    Using +norecurse just tells the nameserver to return whatever information it has (including cached info, if any), so that isn't correct. +trace will work because it will follow the recursion chain all the way to an authoritative server. – Raman Dec 5 '14 at 21:54
  • 1
    Note that I have modified this answer to remove the +norecurse recommendation as it confused the issue. – thomasrutter May 31 '17 at 0:01

Something important to note here, which I notice many people don't ever include when talking about +trace is that using +trace means 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 mx record using dig -t mx example.com and 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 +trace will 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 +trace result 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 +trace revealed.

Can't have too much detail IMO.

  • Does dig have its own cache or uses the OS cache? – CMCDragonkai Dec 22 '16 at 13:04
  • Dig doesn't have a cache. If the upstream nameserver it's using does, though, it benefits from that. – thomasrutter Mar 18 '17 at 13:55
  • dig mydomain.com +trace just returns me the resolvd stub results from 127.0.0.53. See github.com/systemd/systemd/issues/5897 – James Bowery Jun 7 '17 at 23:42
  • When using +trace dig begins the trace using the specified nameserver (eg, 8.8.8.8 if that's what you have configured) for the first lookup (the root zone), but after that it uses the returned nameservers for further queries. So if your configured nameserver is not working or does not properly respond to a query for the root nameservers, you can have problems (as in the above comment). – thomasrutter Nov 5 '17 at 12:01

This bash will dig example.com's DNS entries from it's first listed name server:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
  • The inner dig queries google's DNS (8.8.8.8) to get example.com's nameservers.
  • The outer dig queries example.com's first name server.

Here's the same as an alias for a .zshrc (and probably .bashrc):

# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }

Here's the output for /.:

☀  checkdns slashdot.org                                                                                                dev
-->Server DNS Query

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org.       21600   IN  SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org.       86400   IN  NS  ns3.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns4.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns0.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns2.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns1.dnsmadeeasy.com.
slashdot.org.       3600    IN  MX  10 mx.sourceforge.net.
slashdot.org.       3600    IN  TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org.       3600    IN  TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org.       300 IN  A   216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms

--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms

This solution is complicated enough to be impractical to remember, but simple enough for the problem to not be fixed. dig isn't my specialty - improvements welcome :-)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.