185

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.

Improve this question

5 Answers 5

Reset to default
236

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
Improve this answer
6
  • 3
    Oh okay. Yeah I was familiar with the @ syntax, but haven't had the idea to query the authoritative server instead. Thanks! Commented Mar 21, 2012 at 17:22
  • 4
    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. Commented Mar 1, 2013 at 4:37
  • 7
    What if you're waiting for the authoritative servers to change? Commented Aug 5, 2014 at 12:12
  • 1
    @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. Commented 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. Commented Mar 26, 2018 at 10:47
65

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 perform its own recursive request, which will effectively bypass caching by the intermediate servers. To do this, use the +trace option.

dig example.com +trace

In practice since this will get the final result from 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.

Improve this answer
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. Commented Dec 5, 2014 at 21:54
  • 1
    Note that I have modified this answer to remove the +norecurse recommendation as it confused the issue. Commented 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. Commented 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 Commented Feb 9, 2020 at 22:33
  • 1
    You can use it through the new Windows Subsytem for Linux (WSL) on Windows Commented Mar 12, 2020 at 21:06
28

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.

Improve this answer
4
  • 1
    Does dig have its own cache or uses the OS cache? Commented 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. Commented Mar 18, 2017 at 13:55
  • 1
    dig mydomain.com +trace just returns me the resolvd stub results from 127.0.0.53. See github.com/systemd/systemd/issues/5897 Commented 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). Commented Nov 5, 2017 at 12:01
10

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

Improve this answer
4

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
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.