1.
I thought with "restrict default ignore" settings it was more secure for 
client, which will reject all packets except for server A/B.
At this time I suppose that "restrict default nomodify nopeer notrap noquery" 
setting can permitting to client to synchronize itself to server A/B but will 
not refuse those packets (malicious) which could be sent from other machines 
(different from A/B server). 
Do you agree ?

2.
"restrict default nomodify nopeer notrap noquery".
According to ntpd manual, "nomodify" doesn't permit to modify daemon state but 
I don't understand how ntpd can adjust clock;
that is what's option which permits ntpd to modify local clock time ? 
Does it exist specific option to add "restrict default nomodify nopeer notrap 
noquery" to avoid ntpd can set local clock ?
example:

restrict default nomodify nopeer notrap noquery
server A
server B
server C

I want my client asks time to A,B,C servers but only A,B answers have 
privileges to ntpd can set local clock.
Server C answers must reach ntpd but not authorize to set local clock.
  ----- Original Message ----- 
  From: Richard B. gilbert 
  Newsgroups: comp.protocols.time.ntp
  To: [EMAIL PROTECTED] 
  Sent: Friday, April 13, 2007 3:59 PM
  Subject: Re: [ntp:questions] Linux client ntp


  Steve Kostecke wrote:
  > On 2007-04-13, RICCARDO <[EMAIL PROTECTED]> wrote:
  > 
  > 
  >>I want to use ntpd -qg, it could be right this ntp.conf for my Linux
  >>client ?
  > 
  > 
  >>restrict default ignore
  >>restrict 127.0.0.1
  >>restrict server A
  >>restrict server B
  > 
  > 
  > You could simplify this greatly by replacing all of those restrict lines
  > with this:
  > 
  > restrict default nomodify nopeer notrap noquery
  > 
  > Please see http://ntp.isc.org/Support/AccessRestrictions
  > 
  > 
  >>server A
  >>server B
  > 
  > 
  > When you only have two clocks there is no way of knowing which is
  > correct. Either use 1 or 3 or more.
  > 
  Four or more are better!  Three servers degenerate too easily to the two 
  server case.  Four servers will be somewhat more robust.

  _______________________________________________
  questions mailing list
  [EMAIL PROTECTED]
  https://lists.ntp.isc.org/mailman/listinfo/questions
_______________________________________________
questions mailing list
[EMAIL PROTECTED]
https://lists.ntp.isc.org/mailman/listinfo/questions

Reply via email to