Aliases hostnames resolved every 15 min instead of set 1 hour
-
I am posting it here because the setting is under Firewall & NAT in Advanced Settings. I set the Aliases Hostnames Resolve Interval to 3600 sec which is 1 hour but in my pi-hole I see that aliases are resolved every 15 min, exactly at :00, :15, :30 and :45. It looks like it corresponds to a cron job to reload filters as I have schedules set up and my schedules do use aliases.
I wonder why the interval setting is ignored in this case. I think it should be up to the user to decide how often IPs for aliases can change. I don't see the necessity to tie aliases resolution to filter updates. Is it a feature or a bug?
-
Do developers look here?
-
Some may, others may not (developers looking here, that is) ...
.
As for the answer to your question, it is closer to a feature. Consider this. What if aliases only updated when you specified, but then you went and changed firewall rules (maybe like adding a new alias). Do you want that rule to not work and that alias not resolve for up to the next full hour, or would you as a user expect that alias to immediately start working?
I'm guessing the vast majority of users would expect a new alias, or a new rule referencing an alias, to immediately work. Therefore, when rebuilding the firewall rules (which is what reload filters is all about), the code will immediately resolve all aliases. After the filter reload is complete, then aliases are resolved on the interval specified by the user.
-
@bmeeks said in Aliases hostnames resolved every 15 min instead of set 1 hour:
What if aliases only updated when you specified, but then you went and changed firewall rules (maybe like adding a new alias). Do you want that rule to not work and that alias not resolve for up to the next full hour, or would you as a user expect that alias to immediately start working?
I expect a new alias to be resolved and working immediately after adding or changing it. And then resolve it on the set schedule. This is logical. Firewall rules can use the stored data for aliases at any time. That's why it looks more like a bug.
-
You can open a Feature Request (or Bug Report, as you prefer) on the Redmine Site here: https://redmine.pfsense.org/projects/pfsense.
The issue is that alias data actually lives in a firewall (or filter) table. You can see that under DIAGNOSTICS > TABLES. There you will see a
pf
(packet filter) table for each alias you have defined. I believe that during a filter reload sequence those tables are wiped out and then rebuilt. Thus the aliases have to be resolved again at that time and the tables populated with the data. Been a while since I looked at the complete PHP code, but I think that's how the process works.If the actual hosts you are referencing in your aliases have long-lived TTL values in DNS, then reloading the aliases with each filter reload is a very quick operation as they should be served up from the DNS cache by the local resolver. On the other hand, if those hosts have very short TTL values, I would think you would want them resolved often.
-
@bmeeks It looks like you are correct. I disabled the rules with schedules, the cron job to reload filters disappeared and hostnames resolved every hour instead of 15 min. Let it be the way it is. Although, I don't understand why the scheduling system is so inefficient (maybe not the right term here) - why if I set a schedule to do something twice a week the filters have to reload every 15 min everyday.