Bugzilla Bug 65502

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.