Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
I'm pretty sure bind9 can be configured not to cache. –  derobert Jul 17 '09 at 4: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

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer

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

share|improve this answer
2  
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 1:55
    
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 1:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.