unbound not working

I have a system with some kind of default installation, using local_unbound.
/etc/resolv.conf points to 127.0.0.1, and there is some config in /var/unbound, which contains the nameservers. If I put these nameservers into /etc/resolv.conf, things work correctly.

Otherwise I occasionally see this:
Code:
kernel: Starting local_unbound.
kernel: Waiting for nameserver to start...
kernel:  good

kernel: Wed Feb  1 01:00:55 CET 2017
kernel: Feb  1 01:00:55 ntpd[660]: error resolving pool 0.freebsd.pool.ntp.org: hostname nor servname provided, or not known (8)

and
Code:
# host google.com
Host google.com not found: 2(SERVFAIL)

It happens randomly, about every third system boot. Restarting the unbound does not help, and it seems to be logging to nowhere.
Then, starting it in foreground with -d -d gives these:
Code:
[1485911460] local-unbound[1887:0] info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN
[1485911460] local-unbound[1887:0] info: generate keytag query _ta-4f66. NULL IN

What is going wrong here? Except that the CMOS lithium-cell is empty - or might that be the reason? Are these DNS security stuff bound to a validity timeframe?
 
Oh crap. It wants a very correct date. If the date is off only three days, then it does silently fail and not even report any errors.
 
Yes, a correct date/time on your computer is needed for DNSSEC validation.
You have two choices :
* disable DNSSEC validation in unbound (and it is the wrong solution)
* change your motherboard's battery and set the right date in the BIOS
 
  • Thanks
Reactions: PMc
Yes, a correct date/time on your computer is needed for DNSSEC validation.
You have two choices :
* disable DNSSEC validation in unbound (and it is the wrong solution)
I agree, this might be the wrong solution. But thanks for the info that this is possible (I'm not normally using unbound).
* change your motherboard's battery and set the right date in the BIOS
I can't. This is server hosting service.
 
I can't. This is server hosting service.
Oh! Ok, I understand :)

I have never tried, but maybe you can disable DNSSEC validation for "freebsd.pool.ntp.org" by using the "domain-insecure" directive: https://nlnetlabs.nl/documentation/unbound/howto-turnoff-dnssec/
So, your NTP client would still work correctly and then you would still have DNSSEC validation for all the others domains.

Another solution might be to setup your NTP client with the IP address of one or multiple NTP servers. This way it won't need to resolve the domain name, so won't complain with the DNSSEC validation.
It's not a great solution, because IP addresses could change.
Well, I am not sure if your NTP client or Unbound start first.
 
Oh! Ok, I understand :)
The business somehow reminds me of Pakistan car rental. Battery empty? No problem, just don't switch off the engine.
I have never tried, but maybe you can disable DNSSEC validation for "freebsd.pool.ntp.org" by using the "domain-insecure" directive: https://nlnetlabs.nl/documentation/unbound/howto-turnoff-dnssec/
So, your NTP client would still work correctly and then you would still have DNSSEC validation for all the others domains.

Another solution might be to setup your NTP client with the IP address of one or multiple NTP servers. This way it won't need to resolve the domain name, so won't complain with the DNSSEC validation.
It's not a great solution, because IP addresses could change.
I think I found an acceptable solution: enable ntpdate to run beforehand, and give it a list of hosts as IP-addrs. They don't change frequently, some cheap routers have them even hard-coded, and if only one of them still works, that will do:
Code:
Feb  1 01:00:53 myhost kernel: Starting local_unbound.
Feb  1 01:00:53 myhost kernel: Waiting for nameserver to start... good
Feb  1 01:00:53 myhost kernel: Creating and/or trimming log files.
Feb  1 01:00:53 myhost kernel: Starting syslogd.
Feb  1 01:00:53 myhost kernel: Setting date via ntp.
Dec 13 16:55:38 myhost ntpdate[519]: step time server 145.238.203.10 offset +121967676.827636 sec
Dec 13 16:55:39 myhost kernel: No core dumps found.
Dec 13 16:55:39 myhost kernel: Clearing /tmp (X related).
Dec 13 16:55:39 myhost kernel: Updating motd:
Dec 13 16:55:39 myhost kernel: Mounting late filesystems:.
Dec 13 16:55:39 myhost kernel: Starting ntpd.
 
sysrc ntpdate_enable="YES" and sysrc ntpd_enable="YES". And configure /etc/ntp.conf correctly.

With lots of encryption and authentication schemes (SSL, TLS, Kerberos, DNSSEC, etc) it is imperative your time is set correctly.
 
Note that if the battery of the RTC would be empty the clock typically resets to a date and time somewhere in the '70s or '80s (seems to depend on the clock/BIOS being used) and you may find the system doesn't know how to boot (again, depends on the BIOS, most systems will automatically detect their drives and boot from them). But only if the machine has actually been turned off and on again. A restart would keep power on the chip and thus keep its time (and its BIOS settings). If your time varies between restarts something else is going on.
 
Note that if the battery of the RTC would be empty the clock typically resets to a date and time somewhere in the '70s or '80s (seems to depend on the clock/BIOS being used)...
I've experienced mainly the date getting set to midnight, January 1, 1970, UTC which is The Beginning of Time for POSIX. That works out to 4PM December 31st, 1969 for me, 'cause I'm in California (UTC -8 in winter.)
This is the point - we need to keep this. People are now rather using ntpd_sync_on_start because it is faster - if everything goes well.
Problem is, ntpdate(8) has been deprecated upstream:

It's going to go away eventually.
 
In my experience, when the battery of the RTC fails, the clock reset to a date near the manufacturing date of the mobo (or compilation date of the BIOS or something not that far away).
I have a motherboard from 2005, and the clock used to reset to somewhere in 2005, until I changed the battery :) Same for my daily computer which is from 2008, and was reseting back to somewhere in 2008 when the battery died.

From PMc 's logs:
Dec 13 16:55:38 myhost ntpdate[519]: step time server 145.238.203.10 offset +121967676.827636 sec
seems his clock is reseting to about 4 years in the past.
 
Note that if the battery of the RTC would be empty the clock typically resets to a date and time somewhere in the '70s or '80s (seems to depend on the clock/BIOS being used) and you may find the system doesn't know how to boot (again, depends on the BIOS, most systems will automatically detect their drives and boot from them). But only if the machine has actually been turned off and on again. A restart would keep power on the chip and thus keep its time (and its BIOS settings). If your time varies between restarts something else is going on.

Thats exactly what happens. When issuing reboot or shutdown -r, no problems arise. After issuing halt -p, at restart the time is always precisely Feb 01 2017, 01:00:00 (in CET +0100).
(That's why at first I thought it happens randomly - but that's not the case.)

And when I upgraded to R. 12.2, the make installworld suddenly opened an ANSI dialog asking if my CMOS clock runs GMT or localtime (we know this from the normal installer, but I never got it from installworld - but then, my clocks are usually correct). That dialogue is obviousely lacking a third option "There is no working CMOS clock". ;)
 
This one is architecturally a Silvermont SoC microServer; I don't know the brand and make.

But then, as I understand things: the lithium cell should not even be needed as long as the system stays plugged into mains, because then the 5V standby power should supply the RTC circuitry. This is the S5 state, "soft power off", and this is what halt -p does on my desktop.

The Intel specs for Silvermont say that there is a supply rail that is supposed to receive 3V from a lithium cell, but it is permissibly to not provide such "if the design does not need to preserve information when the system power is turned off".
 
Back
Top