# unbound not working



## PMc (Dec 13, 2020)

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:

```
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

```
# 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:

```
[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?


----------



## PMc (Dec 13, 2020)

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.


----------



## OlivierW (Dec 13, 2020)

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


----------



## PMc (Dec 13, 2020)

OlivierW said:


> 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).


OlivierW said:


> * change your motherboard's battery and set the right date in the BIOS


I can't. This is server hosting service.


----------



## OlivierW (Dec 13, 2020)

PMc said:


> 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.


----------



## PMc (Dec 13, 2020)

OlivierW said:


> Oh! Ok, I understand


The business somehow reminds me of Pakistan car rental. Battery empty? No problem, just don't switch off the engine.


OlivierW said:


> 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:

```
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.
```


----------



## SirDice (Dec 14, 2020)

`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.


----------



## PMc (Dec 14, 2020)

SirDice said:


> `sysrc ntpdate_enable="YES"`


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.


----------



## Jose (Dec 14, 2020)

PMc said:


> ...it does silently fail and not even report any errors.


My experience with Unbound as well. It failed silently enough times that I just went back to BIND.


----------



## SirDice (Dec 14, 2020)

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.


----------



## Jose (Dec 14, 2020)

SirDice said:


> 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.)


PMc said:


> 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:





						DeprecatingNtpdate < Dev < NTP
					






					support.ntp.org
				




It's going to go away eventually.


----------



## OlivierW (Dec 14, 2020)

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.


----------



## PMc (Dec 14, 2020)

SirDice said:


> 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".


----------



## OlivierW (Dec 14, 2020)

PMc said:


> That dialogue is obviousely lacking a third option "There is no working CMOS clock".


Raspberry Pi and similar boards often don't have an onboard RTC


----------



## PMc (Dec 14, 2020)

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".


----------

