Unbound - do I need to "seed" root hints on a clean install?
-
pfSense 2.2.6
I did a fresh install last week on an SG2440 and during the initial setup the router did not yet have internet access. So I was going about my normal setup routine, configuring local domain, LAN subnet, DHCP config, etc. Finally I configured the WAN IP (static ipv4 only). Using unbound (resolver) and no DNS servers entered on System > General and both "Allow DNS server list to be overridden by DHCP/PPP on WAN" and "Do not use the DNS Forwarder or Resolver as a DNS server for the firewall" _UN_CHECKED.
I then tried to browse some test pages from a LAN connected machine….No dice.
I disconnected/reconnected my laptop's cable and refreshed my dhcplease and made sure that my DNS server was pointing to the LAN ip of pfsense (it was). Ping to 8.8.8.8 succeeded so I know internet access was enabled and routing was working ok. I stopped/started unbound to see if bouncing it would help. It did not! I rebooted the router ... and again tested but DNS was still not working.
From Diagnostics of the WebConfigurator I tried to do a DNS Lookup for 'yahoo.com' which failed. So as a last resort I put 8.8.8.8 in under System > General and suddenly everything started working. After a few hours I removed that entry and again left all DNS Servers blank. Everything continued to work fine. I also rebooted the router since then and it continues to work from a cold boot.
TL;DR So long story short my question is: do I need to "seed" unbound with root hints after a fresh install with no working internet connection at the time of initial setup? I found some guides online and even a post on these here forums that suggest running a command like
wget ftp://FTP.INTERNIC.NET/domain/named.cache -O root.hintsbut when I searched my box I found no such root.hints file anywhere on the filesystem and no evidence that such a file would be used. Sorry if this is a dumb question but I searched and could not find a canonical answer.
-
Does anyone know the answer to this one?
-
no you do not need to seed anything… Unbound as resolver out of the box works..
-
Thanks John. Is it possible that a fresh install that has never had internet connectivity gets "stuck" somehow after the initial boot and in a state where Unbound has no root hints until a DNS server is manually entered on the General section? That is pretty much what I experienced. It was strange for sure. I guess I will try some lab tests in VMs that have no connectivity to see if this is actually a thing.
-
no… I don't see how that would be an issue.. I have fired up pfsense on vm multiple times and I never give it any dns server other than itself with unbound and have never had any issue.. The root hints are there, there was a suggestion to allow editing of the root hints, etc.. So you could have your own custom, etc.
But pfsense does not need access to any other dns to know what the root hints are that I have ever seen..
-
There is an occasional issue with unbound initialization if your clock is substantially off (weeks) and you have DNSSEC enabled. Notable on systems that don't have a battery backed clock.
-
Ok so maybe a system that has literally NEVER been booted and thus NTP has not had a chance to set the clock yet, and DNSSEC defaults to being enabled, and the system has no internet access (yet) because it's a manual IPv4 config….... the "PERFECT STORM" so to speak. So maybe it is possible that in that case unbound becomes a little braindead.
What is weird is that even after configuring the WAN IP settings and rebooting it still didn't come alive, until I populated at least one DNS server under System > General. Hmm. Oh well, I know development on the 2.2.x branch is essentially stopped at this point so all efforts are on 2.3 and beyond (which is great) so I will ignore this for now and just note it as one of those possible "gotchas" to look out for.
cheers
-
you sure unbound is working at all? Where did you put this dns, and did you set it to forward mode?
As mentioned you could have issues with clock being off and dnssec to the root servers.. All the roots are signed.. So if dnssec was failing that could cause you problems.
A simple sniff on the wan would of shown you what was going on, if pfsense was doing queries to the roots, etc..
-
Yes I wish I had thought of doing a packet capture at that time but it was late and I was setting this up for someone who was rushing me out the door trying to just get it working as quickly as possible.
Two possible workarounds for this that I could see:
- during initial boot (console) or upon first log in to Webgui- pfSense should prompt you to set the clock if it hasn't been able to sync with NTP yet
or
- DNSSEC should be OFF by default, perhaps with a banner/warning to indicate that it should be enabled after NTP/clock is configured
-
Reminder to set the clock? Not to sound like an ASS, but how dumbed down do we need to make pfsense?
As to dnssec being off?? Yeah then it would stay off for many of the users to dumb to validate pfsense has the correct time, you would expect them to enable dnssec? ;)
To be honest many of the users of pfsense, per some of the threads here on the board don't even understand the difference between a forwarder and resolver - and now you want them to enable dnssec on their own ;) Many of them continue to set a gateway on their lan interface - even when its never asked for during setup, and there is even a note saying it normally is none.. And they end up setting the gateway to itself, etc..
For dnssec to fail with clock being off, I think it would have to be WAY off… Next time I fire up a clean pfsense vm for testing I will set the clock to being years off and see what happens ;) And do a sniff on its first queries for dns.. Will bring it up with wan off.. Then enable it to duplicate what you did..
-
Unfortunately it's a bit of a Catch-22: the default NTP configuration is dependent upon DNS to lookup pool members.
Ok so maybe a system that has literally NEVER been booted and thus NTP has not had a chance to set the clock yet, and DNSSEC defaults to being enabled, and the system has no internet access (yet) because it's a manual IPv4 config….... the "PERFECT STORM" so to speak.
-
Reminder to set the clock? Not to sound like an ASS, but how dumbed down do we need to make pfsense?
What if it only posed that question after first attempting to auto-set via NTP and failing … then I don't see that as "dumbed down" especially if the altetnative is a completely nonfunctional DNS...
-
It could be addressed by having an IP in the default NTP config, but this is generally undesirable.
Another approach would be to have a fail safe command:
ntpq -q -g <ip addr="">to be used only if dns resolution fails. Still, permission to use the time server would need to be secured in advance. Someone like HE might agree. Or perhaps one of the NIST servers.</ip>
-
Yup defaults to pool something for the ntp, so without dns those would fail ;)
And agree it would be really bad practice to hard code a IP for any of the ntp servers.
Maybe that was the issue, maybe time/date was way out of wack. Could not lookup up ntp.pool servers to set time.. Dnssec then failed. Setting a dns for pfsense to use allowed time to sync, and then resolver worked with dnssec now that its time/date was correct. Not so much a perfect storm, but sure a issue that could come up I guess up now and then.
Maybe a step to display time/date/zone in the setup - ask if this is correct, if not suggest to set date/time (I do recall a step setting time zone, and even adjusting the ntp servers I believe?) so that when unbound comes up it will be atleast close enough to work. I will try and duplicate this scenario later today.
-
I ran into it while testing the SG-2220. No battery backup for the clock, so every time the unit booted after power fail the clock would revert to the build time.
It takes a lot to actually encounter the problem. Unbound with DNSSEC must be enabled. The unit has to be removed from power across a roll of of the trust anchor keys. The clock has to go backward a fair bit. The NTP config must be DNS based (if the WAN interface is DHCP and the DHCP server is handing out a NTP server by address, the problem doesn't occur). So many conditions that in the end I decided that it just wasn't that big of a deal.
Maybe that was the issue, maybe time/date was way out of wack. Could not lookup up ntp.pool servers to set time.. Dnssec then failed. Setting a dns for pfsense to use allowed time to sync, and then resolver worked with dnssec now that its time/date was correct. Not so much a perfect storm, but sure a issue that could come up I guess up now and then.
-
I set up another SG-2440 today (a bare metal install freshly flashed from USB) and ran into this problem again. Again I had to put 8.8.8.8 in under General Settings for a minute to get DNS working and then later was able to remove it without consequence.
I wish I had the luxury of more time to grab logs and debug info but I was under a time constraint again. But I should be able to replicate the scenario pretty easily now that I know the basic steps to repro.
-
next time vs putting in google dns, why not just turn off dnssec until you time syncs.
-
If I am reading this correctly I have had the same problem. My first install I had resolver working. My reinstalled of pfsense with immediately turning off IPv6. I added static routes for my other networks. Normally my local LAN lives behind a layer 3 switch in different networks. Everything was working except DNS. If I plugged in my local ISP's DNS servers in the PC IPv4 config it all worked but I had my layer 3 switch handing out pfsense IP for DNS and nobody could use DNS from pfsense. I could ping 8.8.8.8 no problem. I finally uncheck resolver and checked DNS forwarder and everything was working. Next time I will try to seed DNS.
I spent about 2 hours on this because I had just had pfsense working. I could not figure it out why DNS would not work.
I wish I would have seen this thread last night.
PS
I am not using DNSSEC. Just a basic install.
