pfSense DNS cache refresh interval
-
@johnpoz said in pfSense DNS cache refresh interval:
I don't think the table entry would go away at the end of 90 seconds
By go away you probably mean refresh :)
According to the doc https://www.netgate.com/docs/ the default refresh interval for filterdns is 300 seconds like you mentioned.
So my idea of using TTL with a common cache layer will not work unfortunately, too bad because it would be a clean solution.
Perhaps I can trigger a refresh and build an automated process to do it. The doc doesn't have good info on filterdns, I'll try to dig into the code and see if I can find the command that triggers the refresh.
-
No I am saying my guess, is that I look up host.domain.xyz that is in my alias that has a ttl of 10 seconds.. It puts that into the table.. That table will contain that IP forever, until filterdns updates it..
That would be a guess!! But simple enough to test.. Let me put in a record that has say a 60 second ttl... And see if it is removed from the table after 60 seconds.. Even though filterdns only updates ever 300 seconds.
-
Ok I just put in this host for test alias
api-us-east-1-cell-1-2074811574.us-east-1.elb.amazonaws.comIt as a rediculously low ttl of 60 seconds. Which I have complained to them about.. Its a domotz thing that just queries all day long for this - and since its ttl is so freaking short its a lot of freaking queries ;)
Anyway - so I put this in alias..
I then look in the table couple min latter - way past the ttl, and its still in the table.. Once something is put in the table it doesn't just remove itself once any sort of TTL would of expired.
-
@johnpoz said in pfSense DNS cache refresh interval:
Once something is put in the table it doesn't just remove itself once any sort of TTL would of expired.
Right, it doesn't honor the TTL. It appears to be hard coded to 300 seconds, during my test when I wait 300 seconds it refreshes the table with the new IP.
-
So how do you think that is some sort of problem? The ttl of the records is 300 when you get them direct, only if you were getting your info from a forwarder could you get a lower ttl, which would mean you would just have to query it again when that ttl expired..
You sure you just don't have a problem with using different ways to resolve www.google.com so you would be getting different answers between what pfsense lookups and what your clients do - causing a mismatch in where the clients want to go and what is in your alias.
If your forwarding you could for sure get some way different IPs then if you locally resolved..
Resolved
;; QUESTION SECTION:
;www.google.com. IN A;; ANSWER SECTION:
www.google.com. 270 IN A 74.125.69.99
www.google.com. 270 IN A 74.125.69.103
www.google.com. 270 IN A 74.125.69.105
www.google.com. 270 IN A 74.125.69.147
www.google.com. 270 IN A 74.125.69.106
www.google.com. 270 IN A 74.125.69.104;; Query time: 2 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)Asking 8.8.8.8 for it..
;; QUESTION SECTION:
;www.google.com. IN A;; ANSWER SECTION:
www.google.com. 258 IN A 64.233.177.105
www.google.com. 258 IN A 64.233.177.104
www.google.com. 258 IN A 64.233.177.147
www.google.com. 258 IN A 64.233.177.99
www.google.com. 258 IN A 64.233.177.103
www.google.com. 258 IN A 64.233.177.106;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) -
with the new IP.
You mean the large list of IPs? Your table for www.google.com only lists 1 IP?
-
Maybe I'm not thinking about this right but here is what I see happening during some tests.
- pfSense filterdns does a DNS lookup for www.google.com and gets a TTL of 64 seconds
www.google.com max TTL is 300 seconds but depending on when you query it can be anything from 0 to 300.
-
Since PfSense filterdns waits 300 seconds hard coded it will just wait and not honor the 64 TTL it originally received.
-
App Server does a DNS query (separate than pfSense filterdns) for www.google.com and gets a TTL of 64 seconds, it honors the 64 seconds and queries again when it expires.
This creates a disconnect between pfSense and the App Server.
There is one more point here in that you mentioned Google randomly returns IP addresses so for that case using a common DNS layer will ensure that the same IP is returned and managed based on the TTL.
However, since pfSense filterdns does not honor TTL and just has a hard coded 300 seconds that will not work because of the disconnect that happens I mentioned above.
It's possible I'm not thinking about something right but at the moment that is what I see.
-
@exocomp said in pfSense DNS cache refresh interval:
pfSense filterdns does a DNS lookup for www.google.com and gets a TTL of 64 seconds
www.google.com max TTL is 300 seconds but depending on when you query it can be anything from 0 to 300.
This point above is interesting, if I query the the authoritative server (ns1.google.com) for www.google.com I get a TTL of 300 (which is the raw value). However, if I query a Non-authoritative server say 8.8.8.8 (google public dns) I get the time remaining until the next refresh which could be anything from 0-300. I'm not sure what's going on there, I'll need to read up on how that works.
-
When you ask a forwarder or upstream resolver if you will like 8.8.8.8 its going to hand you the TTL of whats left on its cache... When you query authoritative you will always get the actual TTL the owner of the domain has set..
fans of forwards don't normally understand this.. One of the many reasons why its better to resolve vs forward.. Which pfsense does out of the box for reasons ;)
People say oh will when I forward I get a faster response, etc.. Well yeah - your just getting what is cached.. Could actually be WRONG for you based upon your IP and region, etc. And its also going to be a TTL that is less then what the owner wanted since its just whats left in the cache, unless there was no cache and it resolved it? Then you going to have to wait the time for it to resolver or forward plus the added time to query it where ever it is, etc. And if the TTL is not full, its possible it could be something really short and now your just going to have to query again way before you should have to, etc.
If your clients are only asking pfsense for dns, no matter what pfsense does with the answers it gets back should be fine - My guess is you have your clients using different dns than pfsense or both? And you don't know where they are getting their answers from or what, etc. or if your using proxy in explicit mode it would do the queries, etc.
-
This post was really helpful in pointing me in the right direction and got to learn more about how pfSense host alias DNS works and a little more about DNS in general, I was able to come up with a solution given the need.
Thanks for taking the time to help out.
-
Any time - I could discuss DNS for hours and hours ;) So if you ever have any questions about DNS just post a thread I will more then likely see it and comment..
The problem of when a firewall updates its aliases is problem with pretty much every firewall have worked with in the last 30 years when client might use or get something different. When there is more than 1 IP for some fqdn.. Be it based upon geo location of the query or some sort of roundrobin, or from a cache that resolves from a different location then the firewall/user, etc.
It's not just pfsense that such issues can be seen that is for sure.. Blocking of url based stuff is normally done better with a proxy where the proxy so you can base the filter on the actual uri being requested vs the IP of said fqdn in the url.. Proxy also allows for filtering on path or other words in the url and not just the hostname portion, etc.
DNS based lookups and blocking of the IP work fine when its static sort of IPs returned, but when your wanting to talk to something hosted on a CDN that returns lots of different IPs for the same fqdn then yeah you can run into complications.
