0

When I run dig example.com the response comes back with SERVER: 192.168.0.1, even on subsequent runs. That implies DIG is always making a network call to resolve the DNS record.

I (rather ignorantly) assumed that my OS would be caching the DNS record according to its TTL, and that DIG would be using that cache.

Does DIG ignore the TTL / not make use of caches by default? If so, how can I get DIG to use a cache and honor TTLs?

Background / X-Y Problem:

I want a way to quickly resolve DNS TXT records for an nginx script that I'm writing. The script will route requests based on the content of those TXT records, so I'd like whichever method I'm using to honour TTLs and use locally cached records where appropriate.

Lawrence Wagerfield
  • 47
  • 9

2 Answers2

4

dig (domain information groper) as the manual explains, is a flexible tool for interrogating DNS name servers, it does not query or use your local DNS cache (and/or hosts file) but directly queries the name server you point it at. By default that will be the one(s) from /etc/resolv.conf.

To use your systems DNS cache from the command line use getent hosts [ip-address | hostname] or in scripts/code use a native version of the man 3 gethostbyname system call.

Admittedly that does not help your with anything else beyond A AAAA or PTR records.

In dig output the SERVER label is ip-address of the name server dig uses, which will never have a TTL... 

dig ANY www.google.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27695
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.                IN      A

;; ANSWER SECTION:
www.google.com.     173     IN      A       216.58.212.132


;; AUTHORITY SECTION:
google.com.         146915  IN      NS      ns2.google.com.
google.com.         146915  IN      NS      ns3.google.com.
google.com.         146915  IN      NS      ns1.google.com.
google.com.         146915  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     145115  IN      A       216.239.34.10
ns1.google.com.     145115  IN      A       216.239.32.10
ns3.google.com.     145115  IN      A       216.239.36.10
ns4.google.com.     145115  IN      A       216.239.38.10

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)    <========== My Name SERVER is localhost
;; WHEN: Tue Aug 30 22:51:26 2016
;; MSG SIZE  rcvd: 184

I run my own caching DNS server locally rather than using an ISP's or Google's public resolver (8.8.8.8) mainly for spamassassin, which has the advantage of being local, but the cache doesn't get pre-seeded/populated by other users either.

HBruijn
  • 77,029
  • 24
  • 135
  • 201
2

This is really an OS resolver question at its heart, but you did not specify the operating system. Since dig is mentioned, I'm going to assume that we're working with some flavor of UNIX here.

UNIX based operating systems do not implement a DNS cache within the kernel itself. There are a few topics that need to be summarized before we get into how it's actually implemented.

NSS

Calls to the resolver library typically implement their lookups using Name Service Switch (NSS), a modular system for specifying data sources to use and the order in which they are looked up. You can find a list of these module stacks in /etc/nsswitch.conf. For reference, the one we're concerned with here is hosts.

It is not recommended to play with the hosts entry in /etc/nsswitch.conf unless you really know what you're doing. Reordering these modules can result in funky things like DNS consulted before the /etc/hosts file!

nscd

Prior to consulting the module stack, NSS checks for the presence of a running nscd socket and attempts to query it. If nscd is configured to maintain a cache for the NSS database in question, it's possible that an entry cached by nscd will be returned without the NSS modules being consulted. Most Linux distros that I know of do not enable caching of the hosts database by default, and /etc/nscd.conf must be customized.

That said, it should be noted that many administrators consider the "stock" nscd daemon to be unreliable, at least under Linux. There is at least one alternate implementation out there. Your mileage may vary.

Putting it all together

Knowing the above, the lookup order for the hosts database works in this order:

  • nscd (if running, its socket is present, and caching of hosts is enabled)
  • NSS modules, in the order listed in /etc/nsswitch.conf
  • If not found in a NSS module, it doesn't exist.

This brings us to where dig falls into this equation. You can pretty much refer to HBrujin's entire answer (dig doesn't use NSS, only talks over TCP/IP), but the catch is that there is no cache for NSS at all unless 1) nscd is running, and 2) it is configured to cache the hosts database.

tl;dr

The complexity of getting DNS caching to play nicely within NSS is usually why most admins go with the "simpler" solution of running their own recursive DNS server. You don't need to know a darn thing about NSS. Just point /etc/resolv.conf at your shiny new DNS cache and let it hide the evils of NSS from you. (at least until you need to learn how LDAP integration works)

Andrew B
  • 32,588
  • 12
  • 93
  • 131