Force dig to resolve without using cache

Solution 1:

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

Solution 2:

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.

---

Solution 3:

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.

---

Solution 4:

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