Occasional DNS lookup failures - how to troubleshoot?
I'm running a NetGate RCC-VE 2440 router with 2.4.5-RELEASE-p1. A few weeks ago, I started using pfBlockerNG-devel, currently on version 2.2.5_34. Over the past few weeks, I'm getting DNS lookup failures on my devices. I've seen this happen on my iPhone going to the App Store, on my Windows 10 PC browsing to a website, and even on my Xbox. In every case where I get an error attempting to get to the site, if I refresh or try again within a couple of seconds, it can then find the site and continue. I would estimate that I see this anywhere from 3-5 times a day.
I'm not trying to pin the blame on pfBlocker for this, but the addition of that package is certainly the change in my environment over the past few weeks. How can I troubleshoot where the problem is occurring?
Yeah if you use a lot of lists and data in pfblocker can delay unbound from startup when it reloads on say a dhcp renew..
The simplest solution currently is to prob just not have unbound restart on dhcp leases.
@teamits, yes, unbound was restarting quite often, and it looks like those restarts were coinciding with DHCP leases. I did have the "Register DHCP leases in the DNS Resolver" option in the DNS Resolver section enabled. I have disabled that option, and haven't seen any restarts in unbound in an hour, as opposed to the 20 (!) restarts of unbound in a 24-minute period before disabling that option. I already had host overrides for servers and other devices at home that I wanted to reach by name, so I'll just add entries there for anything else I want to reach by name on my LAN.
I'll check the logs in the next day to make sure this resolves the issue, but pretty sure this is the right option. Thanks!
Gertjan last edited by
yes, unbound was restarting quite often, and it looks like those restarts were coinciding with DHCP leases. I did have the "Register DHCP leases in the DNS Resolver" option in the DNS Resolver section enabled. I have disabled that option, and haven't seen any restarts in unbound in an hour, as opposed to the 20 (!) restarts of unbound in a 24-minute period before disabling that option
So, pfBlockerNG installed, or not, this situation existed already.
Instead of (DNS) host overrides, use Static MAC based DHCP leases for your devices => DHCP / resolver issue solved.
pfBlockerNG can still create 'DNS' issues.
Just try this one : load in huge numbers of DNSBL feeds, something close to the systems memory size.
Have them reloaded every hour ***.
You'll see that the resolver will get restarted , and that it will take many (tens of) seconds to restart, as it has to parse out all these lists (prepared and stored in one big file by pfBlockerNG ).
Always keep checking the logs if you make big changes to your router/firewall, as starting to use packages like pfBlockerNG .
Ask yourself always the same question again : "what happens if I add or remove or change this/a functionality X"
*** because it is happening all the time : even when people are informed that a feed is updated ones a week, they (can) set it up for a 1 hour renewal/download, thus overloading the hosting server, thus forcing the feed-author to stop publishing the feed for $$$ reasons (hosting a server never includes a unlimited bandwidth).
I know this topic has been covered in depth, and there are some great workarounds.
One thing I would point out is that if you really, really, want to run with the "Register DHCP leases in the DNS Resolver" turned on, and the unbound restarts are killing you, consider changing the default lease time in the DHCP server, if you can.
It is set to 7200 seconds, and with compliant clients renewing at half-life, you could potentially get "# of active leases" restarts per hour.
Longer lease sure yup can help for sure..
Let me throw this out there for discussion.. In a home setup, how many actual devices do you have.. Why not just setup reservations for them?
Yeah in modern homes you can for sure end up with a lot.. I have to be prob in the 30 range and its just me and the wife ;) But then again we all have phones, and tablets and lots off other smart devices, etc.
But just add reservations for them, even just a few a day and pretty soon all your devices have reservations for specific IPs.
So really the only time a device would get an IP from dhcp that you don't already know what its going to be is new devices (add them to reservations as you get them) and guests.. Do you really give 2 shits about guests? If you always have billy coming over with his phone, you can then add it to reservations as well.
Unless you are on a network with 100's and 100's of devices its really minor work to just make sure you devices always use the same IP.. This makes management (via firewall rules) easier to be honest. I know for example my ipad on any specific vlan will have IP xyz, so can easy create rules for it, etc.
Now you don't have to worry about unbound restarting all the time.. And you always know what IP device X is going to be.. Its just a small amount of upfront work is all.
jwj last edited by jwj
A while back I went through all of the devices on the home network. Created a worksheet with the MAC addresses for each device. Which ones are wifi and which ones are wired. Then started arranging them into groups that would later become VLANs. Went through a few iterations and ended up grouping by "access". Which ones need to only see the internet. Which ones have no internet access. Which ones need to see devices in another group, say a printers group. Like that. Also remembering that you are segregating/isolating devices for a reason. Don't do that if you then immediately break that segregation by a rule for one specific device in a group. It should take more than a minute to work it through. Then I assigned ip's to each device that are consistent across VLANs. Those become DHCP reservations. There's a system to it that I understand at a glance.
The worksheet than becomes the source used to create VLANs on your switch(s) and in pfsense. The source used to determine what VLANs get what rules. The source used to setup SSIDs on your wireless access points for different VLANs. Even if you F it up really bad and loose all your configurations you won't have to rethink everything again. It's the master template. Keep it up to date.
Fundamentally, what would be the difference between a DHCP reservation and an infinite DHCP lease (lease time of -1?)?
infinite DHCP lease (lease time of -1?)?
Many clients would not accept that would be one reason why that might not work.. While with a reservation client would renew it, or even come back say after 3 months of being down and still get the same one.
Also with lease of -1, when would the client check for new info.. You could set a reservation for say 4 hours.. And you know that hey every 2 hours roughly client will come and renew, and you can hand them new info - like new dns to use, or different ntp server, all the things that you can hand out with dhcp for example.
Or change the IP they are suppose to use.. With something like an -1, when would they come back and say is this IP still good for me to use, or should I use something different.
Thanks for the replies, everyone. Unbound has not restarted since unchecking registration of DHCP leases in DNS Resolver, so DNS lookups are solid and responsive now.
I have been considering configuring DHCP reservations on my LAN. I probably have close to 70 devices that use DHCP, but I've already identified over 50 of them. The true benefit here is just being able to identify what you know and don't know on your own network, which is good! So I guess I'll plug away at identifying a few more devices here and there until I have all of it figured out and configured for static DHCP mappings.
Looking at your dhcp leases should help... Most devices register a name - that should help you identify them.. If its something odd.. Looking up the mac address should tell you who made it, or atleast the nic/wifi card its using.
If wired another way to figure out what a device is, if you have smart switch that will show you the mac address table is look up the mac to what port its on, and then just trace the wire.
Many devices also list their mac on them, or can be found in info screen, etc. If trying to figure out which mac belongs to what - normally a reboot of said device will have it check its lease - so looking in your dhcp log for timestamp of what just asked as you rebooted it.
another option - if all your devices answer ping, some iot devices don't.. Is do a ping sweep for what answers, then turn off some device you don't show in your list, and do your ping sweep again - what was the IP that answered before, and now doesn't ;) What device did you turn off ;)