From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET
CLR 1.1.4322)
Description of problem:
When using ntp-4.2.0-7, every query using 'ntpdate' returns 'no
server suitable for synchonization found'. Running 'ntpdate -d' shows
five 'transmit' attempts to the IP address of the NTP server with
no 'receive' responses. Before you scream 'it's yer firewall', note
that if I uninstall ntp-4.2.0-7 and reinstall ntp-4.1.2-5 from Fedora
Core 1, and recycle the same configuration file, everything works
perfectly without changing *anything* else about the system.
Version-Release number of selected component (if applicable):
ntp-4.2.0-7
How reproducible:
Always
Steps to Reproduce:
1. Install ntp-4.2.0-7
2. Configure a basic /etc/ntp.conf, syncing to an outside time source
3. Start the daemon (service ntpd start)
4. Observe that 'ntpq -c peers' output appears to be good
5. Run 'ntpdate -u localhost'.
Actual Results: The above described error was observed. No outside
hosts can sync.
Expected Results: ntpdate should be working, as it does with version
4.1.2-5.
Additional info:

I'm not completely clear on what the reporter means by "No outside
hosts can sync" ... but if he means that he has a server configuration
on his FC2 machine, and outside _clients_ can't sync, then there's a
change between ntpd 4.1 and 4.2 which might explain his problem.
It seems that the meaning of the 'notrust' option of restrict has
changed between 4.1 and 4.2 with the result that server configurations
that worked with 4.1 fail silently with 4.2. Details can be found in
the thread starting here,
http://mailman.ntp.org/pipermail/questions/2004-July/004089.html
It also seems as tho' the 'authenticate' keyword which is used in the
default client ntp.conf that's generated during installation has gone
away in 4.2 ... I'm now seeing lines like,
ntpd[18362]: configure: keyword "authenticate" unknown, line ignored
in /var/log/messages when ntpd is started.

That was *exactly* the problem. Removing 'authenticate yes' and all
references of notrust from the config file is allowing things to work
now, no more inexplicable dropped packets.
I'm not sure why, but I was still having this problem whilst
connecting to localhost even though I had set "restrict localhost"
(with nothing following it).
I'm utterly flabbergasted that such a change would be made in the
interpretation of the config file silently. What ever happened to
deprecating an old meaning in favor for a different, new meaning? I'm
glad that setting "notrust" didn't suddenly mean "Remove all files
from /var".

Created attachment 103067[details]
Patch for ntp.conf
This patch removes the "notrust" restriction from ntp clients; this restriction
is no longer needed as its meaning has changed since older versions, and in
fact may prevent clients from accessing the time server if present.
The old "authenticate" keyword is also commented out.