169

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.

5 Answers 5

223

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
6
  • 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, 2012 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, 2013 at 4:37
  • 7
    What if you're waiting for the authoritative servers to change?
    – the
    Aug 5, 2014 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, 2014 at 6:46
  • 8
    you can also check on google dns dig @8.8.8.8 example.com. the records appear much faster there. Mar 26, 2018 at 10:47
60

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

5
  • 13
    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, 2014 at 21:54
  • 1
    Note that I have modified this answer to remove the +norecurse recommendation as it confused the issue. May 31, 2017 at 0:01
  • I have not been able to find this "dig" command. It does not appear to be a standard Windows command. A command prompt gives me an error message. Feb 7, 2020 at 13:30
  • 2
    @DavidSpector dig is a software tool that comes with BIND by ISC - while it's common on Linux it is officially available for Windows too, from Bind's website. Download the current stable Windows version of Bind as a zip, unzip and look for dig.exe - for more instructions Google for Using the dig dns tool on Windows. Do NOT follow any instructions which include copying files into /Windows/System32 Feb 9, 2020 at 22:33
  • 1
    You can use it through the new Windows Subsytem for Linux (WSL) on Windows Mar 12, 2020 at 21:06
25

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.

4
  • 1
    Does dig have its own cache or uses the OS cache? Dec 22, 2016 at 13:04
  • 1
    Dig doesn't have a cache. If the upstream nameserver it's using does, though, it benefits from that. Mar 18, 2017 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 Jun 7, 2017 at 23:42
  • 1
    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). Nov 5, 2017 at 12:01
7

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 :-)

3

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:

dig @8.8.8.8 +nocmd _acme-challenge.ultrasecretprojec.to txt +noall +answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .