3

I am working on an application that will be used to verify new domains are configured correctly as they're set up for hosting. Part of this checks the validity of SPF, DomainKey, DKIM records, etc.

I currently use a default TTL of one hour for most of these records. Occasionally a mistake is found in one of the records so it needs to be updated. Currently, if I've just tested the domain I have to wait for the system's resolver's cached record to expire before I can verify it is correct with my application. (Yes, I can check manually but I wrote the application so I don't have to).

I would like to set up a DNS server on the system to act as a normal caching resolver except that it will expire records in a maximum of a set time such as five minutes or just not cache at all. Not all of the domains have DNS hosted on my normal name servers so this system would have to query the authoritative name servers for a domain rather that use upstream resolvers (which would just use their cached records).

This machine is not currently running DNS of any kind so I can install BIND or djbdns (or something else if there's a good suggestion.

Dave Forgac
  • 3,486
  • 7
  • 36
  • 48
  • I'm pretty sure bind9 can be configured not to cache. – derobert Jul 17 '09 at 04:11
  • Why bother with a caching nameserver at all? Why not just query the authoritative nameservers for the domains directly? No caching issues then. – Jason Tan Jul 17 '09 at 11:52
  • The application uses the system's resolvers and I'd rather set up a new resolver than have to code this behavior myself. – Dave Forgac Jul 17 '09 at 12:12

4 Answers4

11

Thank you all for your input and suggestions. They directed me to the following solution:

  • Install bind9.
  • Edit /etc/bind/named.conf.options so that the forwarders are blank (so the server doesn't use another caching server's cached records).
  • Set the max-cache-ttl and max-ncache-ttl options to 300 seconds. (reference)
  • Change listen-on-v6 { any; }; to listen-on-v6 { localhost; }; so the server isn't used by other systems. (reference)
  • Edit the system's /etc/resolv.conf to only include nameserver 127.0.0.1 so apps on the server use the new local server.

I restarted bind9 and verified it's working:

dev:~# dig serverfault.com

; <<>> DiG 9.5.1-P2 <<>> serverfault.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63591
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        300     IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        300     IN      NS      ns21.domaincontrol.com.
serverfault.com.        300     IN      NS      ns22.domaincontrol.com.

;; Query time: 190 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 18 03:06:24 2009
;; MSG SIZE  rcvd: 101

TTLs are showing as 300 even though serverfault.com's record's published TTLs are 3600.

Dave Forgac
  • 3,486
  • 7
  • 36
  • 48
1

Just make calls to "dig" use +trace alot...

Dig will act just like a DNS server an go do full recursion, no cashing, no need to know NS servers ahead of time and if there is a delegation issue you will find that too.

If its a Windows program you can download Bind from here https://www.isc.org/download/ and it contains a dig.exe, Linux there is usually a BIND tools or maybe Named tools package available that will contain dig.

Installing a whole DNS server just to do lookups... insane!

$ dig www.google.com +trace +nodnssec -4

; <<>> DiG 9.11.9 <<>> www.google.com +trace +nodnssec -4
;; global options: +cmd
...

...

google.com.             172800  IN      NS      ns4.google.com.
;; Received 291 bytes from 192.48.79.30#53(j.gtld-servers.net) in 22 ms

www.google.com.         300     IN      A       172.217.10.228
;; Received 59 bytes from 216.239.32.10#53(ns1.google.com) in 30 ms
Robert Eachus
  • 11
  • 1
0

Why not just use dnscache (from the djbdns suite) and kill it every 5 minutes?

For those of you who haven't used djbdns and specifically dnscache -- it is a recursive resolver that doesn't keep anything on disk at all. Also, djb made a suite of tools that automatically monitor a program and if it dies the monitoring program will automatically (and instantly) restart it.

Kill it every 5 minutes and bob's your uncle...

chris
  • 11,784
  • 6
  • 41
  • 51
  • 4
    downvoted, not because it's djbdns, but because it's a horrible hack. any decent caching server would let you override the maximum cache lifetime. – Alnitak Jul 18 '09 at 20:29
  • The whole situation is a bit of a hack though, isn't it? I publish a DNS record with a particular TTL, that's the TTL that should be reflected in a cache. It's a bit of a angels on pinheads sort of situation, but which is better, storing a lie (overriding the ttl) or frequently forgetting the truth (wiping the whole cache). Jason Tan's answer really is the best of the lot. – chris Jul 19 '09 at 01:55
  • 2
    No, the published TTL reflects the _maximum_ time that something should be retaining in cache, not the _minimum_. In that sense it's an advisory value. Overriding the cache value (as with Bind's maximum-cache-ttl setting) is not "lying", it's semantically the same as dropping cache entries because of cache size limits. What _is_ incorrect (but done regardless :( ) is storing values in the cache for longer than the authoritatively specified TTL. – Alnitak Jul 19 '09 at 11:44
  • Okay, I'll accept that you can ignore the ttls and wipe them more often. The (bind9) example solution described by Dave doesn't seem to do only that, though. The dig response includes the ttl amended by the caching server (300) not what's actually published by the authoritative server. Not that it matters, really, but I think it is noteworthy. – chris Jul 19 '09 at 16:20
  • Well for this application I'm only making the server available to localhost so no one else is seeing the records with the lower TTL. I like using a TTL of 3600 on authoritative name servers to reduce the number of queries it gets but in this case I need to make sure I'm getting a fresh copy of the DNS. It beats lowering the TTL, making a change and testing it, and then setting the TTL back after testing. – Dave Forgac Jul 20 '09 at 01:25
  • @chris - that's the correct behaviour. that's so that client stub resolvers can themselves cache the response knowing when the latest point when that entry will expire will be. – Alnitak Aug 10 '09 at 08:30
0

You can, as you say, limit the longest TTL with max-cache-ttl and max-ncache-ttl, either in the BIND options clause, or a view that only applies to your development server.

However, that affects the TTL of all lookups, so would increase network/load on a production server and decrease DNS resilience.

For BIND 9.3 and above, if you just want to clear the cache for one domain, you can do 

rndc flushname <domain>

This flushes all records for the exact domain, not subdomains. See the output of rndc.

Of course, if you want to lengthen the TTL for any reason, that is another question.

Cedric Knight
  • 1,098
  • 6
  • 20