Bug 132787 - ntpd should use pool.ntp.org as default server
Summary: ntpd should use pool.ntp.org as default server
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-date   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-17 01:58 UTC by Rik van Riel
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-12 12:20:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Rik van Riel 2004-09-17 01:58:40 UTC
Description of problem:

users need to search around for an ntp server they can use and the
public stratum1/2 ntp servers have too many users as a result


have the default ntp.conf refer to pool.ntp.org, so users have working
ntp by default without overloading the stratum1/2 servers

Debian is doing the same and it seems to be encouraged by the people
running the ntp pool servers (nearly 200 servers in the pool currently
- with automagic quality controls to remove desynced or badly
reachable servers from the pool)

[ccing jgarzik because he appeared interested too]

Comment 1 Nils Philippsen 2004-09-17 08:49:34 UTC
Just built s-c-date-1.7.8-1 which has pool.ntp.org as the first choice
for NTP servers.

Comment 2 Harald Hoyer 2004-09-21 14:54:18 UTC
errr... and which ip address???
$ host pool.ntp.org
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address
pool.ntp.org has address

Comment 3 Jeff Garzik 2004-09-21 16:51:34 UTC
It's a DNS list of IP addresses...  you use the DNS name, not the IP

ntpd will figure things out from there.

As the instructions at pool.ntp.org related, a typical configuration
looks like

     server pool.ntp.org
     server pool.ntp.org
     server pool.ntp.org

Comment 4 Jeff Garzik 2004-09-21 16:53:46 UTC
er, make that "like the instructions at www.pool.ntp.org related"

Comment 5 Harald Hoyer 2004-09-22 08:13:29 UTC
well, for security reasons, we have in ntp.conf
"restrict default ignore"
which does not permit any host to connect.
In order to open this for an ntp server you have specify an ip address.

restrict nomodify notrap noquery

Also the advisory for ntp.conf is to specify the ip address and not
the hostname.

Comment 6 Jeff Garzik 2004-09-22 14:49:05 UTC
Correct, I assumed you would figure out the correct 'restrict'.  What
I use is

restrict otherntp.server.org mask nomodify notrap noquery

With regards to IP addresses, you should _not_ use IP addresses as
they change periodically with the pool.  The hostname should be used.

It's better than specifying IP addresses, because the pool.ntp.org
people can remove a malfunctioning or cracked server without causing
anyone any downtime.

Comment 7 Harald Hoyer 2004-09-22 14:56:21 UTC
well, we could change the default policy:

restrict default nomodify notrap noquery

Comment 8 Nils Philippsen 2004-09-28 15:07:35 UTC
I've removed pool.ntp.org from the list of default choices in s-c-date
for now, as s-c-date resolves the name and puts _one_ of the IPs into
/etc/ntp.conf and /etc/step-tickers. I've opened a bug against
s-c-date (bug #133925) re handling of multi-homed time servers.

Comment 9 Jeff Garzik 2004-09-28 15:09:26 UTC
Yes, that's definitely a bug.  The hostnames, not IPs, need to be
present in /etc/ntp.conf.

Comment 10 Harald Hoyer 2004-09-29 08:32:05 UTC
normally not... hostnames are not recommended, because of security

Comment 11 Jeff Garzik 2004-09-29 15:38:15 UTC
-specifically- what security reasons are those?

Just about -every- other service and app in the entire distribution
trusts DNS, so I don't see how DNS is any less secure.

DNS is typically -more- secure than IPs, because responsible sysadmins
are more likely to control DNS.  An IP has no obvious trust relationship.

Comment 12 Rik van Riel 2004-09-29 15:43:09 UTC

I would have to agree with Jeff here.  Unless you have a specific
security concern, I think we should just use pool.ntp.org ...

Comment 13 Harald Hoyer 2004-09-30 09:13:55 UTC
ok, then s-c-date should generate a ntp.conf with:
restrict default nomodify notrap noquery

and all should work. I'll set it as a default in ntp.

Comment 14 Harald Hoyer 2004-09-30 09:29:23 UTC
restrict default nomodify notrap noquery
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server     # local clock
fudge stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay  0.008
keys            /etc/ntp/keys

Comment 15 Harald Hoyer 2004-09-30 09:52:43 UTC
handing over to s-c-date

Comment 16 Nils Philippsen 2004-09-30 13:58:39 UTC
As s-c-date tries to leave ntp.conf intact (i.e. works with the
original ntp.conf, doesn't just write a new one), I guess this means:

- get new /etc/ntp.conf template from ntp (for cases where
/etc/ntp.conf is missing)
- do not resolve names into IPs or vice-versa, just leave them as they are

Right, Harald?

Comment 17 Nils Philippsen 2004-09-30 14:00:44 UTC
Ahh and obviously:

- if name resolves into multiple IPs, install aforementioned restrict
line instead of one that would be valid only for one IP

Comment 18 Nils Philippsen 2004-12-13 16:37:43 UTC
well, comment #17 kind of conflicts with comment #16 (re nslookup), as
s-c-date-1.7.15 doesn't do nslookups at all (unless we can do it non-blocking in
a sane way this will stay that way), DNS involving sanity checks will have to wait.

Comment 19 Nils Philippsen 2005-01-15 10:34:25 UTC
s-c-date CVS has now the updated ntp.conf template

Comment 20 Nils Philippsen 2005-10-12 12:20:27 UTC
Fixed long ago in Rawhide.

Note You need to log in before you can comment on or make changes to this bug.