ntpd security looks for the matching "restrict" line. when it finds it, it uses its security settings and ignores all the other lines, especially the "restrict default" line! only if no match is found, "restrict default" is used. i suggest generation of restrict lines as follows: 1) restrict default nomodify nopeer 2) restrict 127.0.0.1 the outcome of these two lines is: the localhost may configure the local ntp daemon. all other hosts may query it, but they may not change anything. nopeer is important, otherwise other hosts can change our time by playing bad peers. there is no need for any more other "restrict" lines. i dont think that the generated network based line is secure: restrict 192.168.0.0 mask 255.255.255.0 this means that all hosts in our LAN can modify the local hosts clock... imagine a public LAN, where notebooks can be attached and it's possible to change time on other hosts. the "notrust" option is wrong in all cases. "notrust" implies copying a secret file from the server to the clients and injecting it with the ntpq console. i am sure that's not what a dhcp autoconfigured host wants to do. the restrict line for the server itself is also not neccessary. my host is syncing to the server even though in theory the server is not allowed to do this. Reproducible: Always Steps to Reproduce: start dhcpcd, and it generates a new ntp.conf Expected Results: restrict default nomodify nopeer restrict 127.0.0.1 no other restrict lines.
yes, with the generated ntp.conf no synchronization was possible
*** Bug 64171 has been marked as a duplicate of this bug. ***
This bug is over a year old and seems to imply that dhcpcd is generating faulty /etc/ntpd.conf files. This should be fixed with dhcpcd-2.0.0 - re-open if anyone disagrees.
