DNSSEC issues related to innacurate system time after boot.

ggwolf · 2019-05-01 03:51:00

I have wifi working and routing properly with netctl, but DNS queries fail without manual help after a reboot. I debugged this to find that it is because my hardware clock doesn't hold time across power cycling, which causes DNS queries to fail because of a DNSSEC error.

What is the best way to resolve this issue? Can I use an IP instead of a domain name in ntpd.conf? I need to get out on the internet to correct my clock but I need to get my clock ballparked to resolve DNS queries.

Last edited by ggwolf (2019-05-01 03:54:09)

seth · 2019-05-01 07:08:05

You could use an early ntpdate call (in order to not pollute your ntp.conf or /etc/hosts w/ static IPs, eg. the *.arch.pool.ntp.org things will all resolve different servers from a pool on every subsequent resolution) and save the IP of a (hopefully still) usable NTP server by resolving the IP of a pool server before every shutdown (to keep them up to date as possible) and storing that in some file.

Can I use an IP instead of a domain name in ntpd.conf?

If only that was documented somewhere …

man ntpd.conf

Zod · 2019-05-01 10:38:39

Why isn't the hardware clock keeping time?

seth · 2019-05-01 11:55:57

No battery?

That would be common on i think eg. a raspberry pi - of course that would mean OP is using ALARM ;-)
Could also just be a dead battery on his mainboard and a hard power switch.

ggwolf · 2019-05-05 22:36:37

seth wrote:

You could use an early ntpdate call (in order to not pollute your ntp.conf or /etc/hosts w/ static IPs, eg. the *.arch.pool.ntp.org things will all resolve different servers from a pool on every subsequent resolution) and save the IP of a (hopefully still) usable NTP server by resolving the IP of a pool server before every shutdown (to keep them up to date as possible) and storing that in some file.
Can I use an IP instead of a domain name in ntpd.conf?
If only that was documented somewhere …
man ntpd.conf

You're right. shame on me for not checking the man page.

Zod wrote:

Why isn't the hardware clock keeping time?

I'm not sure, to be honest. just switched to Arch from Debian testing and it was stuck for several days at 2019 April 24th, 11 PM EST.

I am running on a librebooted x200. I flashed libreboot from whatever release I was running to latest and that seemed to fix my hardware clock, making this topic moot for me but unfortunately with no real "solution" for what if your hardware clock skew prevents DNSSEC authentication. If I still had the problem I would probably go find the real IP of whatever NTP server to my ntpd config.

Thank you all for your responses. How should I mark this thread?

Last edited by ggwolf (2019-05-05 22:45:41)

Zod · 2019-05-05 23:11:00

What I do is set the hardware clock to UTC and in linux make sure my timezone info is correct.

NTP then works fine. I also have windows 10 on this laptop and windows screws with the hardware clock, there is a registry entry that stops windows from doing that.

https://wiki.archlinux.org/index.php/System_time

Last edited by Zod (2019-05-05 23:12:56)

seth · 2019-05-06 06:40:13

[SOLVED] - the hwclock issue was apparently a libreboot bug and you have an answer on how to deal w/ a bad initial clock.

@Zod, this is not a timezone disparity where OtherOS™ insists on a localtime clock; his hw clock was broken (apparently on the BIOS/UEFI/libreboot level) and produced a static date.

Arch Linux

#1 2019-05-01 03:51:00

DNSSEC issues related to innacurate system time after boot.

#2 2019-05-01 07:08:05

Re: DNSSEC issues related to innacurate system time after boot.

#3 2019-05-01 10:38:39

Re: DNSSEC issues related to innacurate system time after boot.

#4 2019-05-01 11:55:57

Re: DNSSEC issues related to innacurate system time after boot.

#5 2019-05-05 22:36:37

Re: DNSSEC issues related to innacurate system time after boot.

#6 2019-05-05 23:11:00

Re: DNSSEC issues related to innacurate system time after boot.

#7 2019-05-06 06:40:13

Re: DNSSEC issues related to innacurate system time after boot.

Board footer