Caching DNS in pfSense
-
I can see that if I do a "dig google.com", I get the results back in xx milliseconds… If I do it again, the query time is only 1 ms, proving that caching is going on.
How long does it cache? I'm asking because I tried digs on several sites that I had visited earlier today (using the exact URL from my bookmarks page - So, if I go to www.arstechnica.com, that's what I did the dig for, not arstechnica.com) and in only one case did I get a 1 ms reply from a site visited hours ago. All the others went through full DNS lookups.
I realize that it may be listening to the TTL time in the DNS reply, and only caching it for that long, which would probably explain what I'm seeing, but I wouldn't expect so many sites to have TTLs short of 6 hours...??
Is there a way to change the default cache time? So that they can be cached for a minimum of 24 hours or something?
Thanks,
Paul -
Not sure but this will break any dyndns urls (especially if they are run in germany where providers usually drop your line every 24 hours to get you a new IP).
-
That is true for some users..
This doesn't appear to be much of an issue though, considering the number of replies I've gotten so far.
-
Perhaps I've found the answer…
According to this page:
http://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.htmlDnsmasq only caches 150 names by default:
-c, --cache-size= <cachesize>Set the size of dnsmasq's cache. The default is 150 names. Setting the cache size to zero disables caching.
So, would anyone else be interested in adding an option to increase this?
If not, if I added the option, could it be added to pfSense? (I'm can commit to the monowall repository, if it helps me qualify to submit code)
Paul</cachesize>
-
Would be a fine option. Can you submit a diff against head?
-
Give me a few days to get up to speed.. I haven't even downloaded the developer edition yet…
I'll have to look through the docs to get started.
-
http://www.pfsense.com/~sullrich/RC2a/pfSense-Developers.iso is the latest version.
Good luck!
-
Poked around a bit more and I'm not sure that this option will help me… By sending a SIGUSR1 signal to dnsmasq, it puts stats for the cache in the syslog (though they are not very verbose)..
From the previously sited man page:
When it receives a SIGUSR1, dnsmasq writes cache statistics to the system log. It writes the cache size, the number of names which have had to removed from the cache before they expired in order to make room for new names and the total number of names that have been inserted into the cache.
So, a kill -USR1 for my dnsmasq process gets me:
dnsmasq[2588]: cache size 150, 0/2391 cache insertions re-used unexpired cache entries.
If I'm reading this right, it looks like 2391 dns names have been cached since my last restart, and of those 0 have been removed before they expired… So, I take it that they are all expiring, possibly based on TTL.
I'm thinking that adding this option wouldn't buy me anything, though it may be useful for people who have large and very busy pfSense machines.
Another thing that I was considering adding to pfSense is my State table from Monowall. I'd just have to parse pftop instead of ipfstat. The big advantage to using it over pftop is that you could also do statistics snapshots, then do a delta, so you can see who is using the most bandwidth at that moment... (Of course, you may be able to do something similar with pftop, not sure)
I'll grab the Dev ISO and see if I can install it in a VM and get started with something, probably this weekend.
-
Once your in pftop, run ? to see all of the options. You can sort by rate, bytes, etc.
-
In looking at pftop closer, it looks like the only advantage my states page has is that you can view delta values. So, if you have long-lived connections, you can view the delta value of how much data has been transfered since you took the snapshot. So, that would let you see who was using the most bandwidth since taking the stats snapshot…
Plus, it's a nice interface that is convenient to see via the webgui.
-
I am all for it. Thats something that could be included in 1.0 immediately as a package, too.