NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

The query-on directive

Description

The query-on directive specifies which addresses or interfaces to use for outgoing queries instead of relying on ntpd and the operating system to pick an address for you. In the absence of this directive ntpd will make its own choice. The last address or interface found that exists will be used to send out the query packet. The socket will then be designated to accept packets arriving on this interface. This is necessary since the replies to the NTP queries will be returned on that address.

The query-on directive takes an address or interfaces and will optionally take a port number or a keyword.

Subsequent query-on directives will append to the existing list. The last valid address/interface listed will be used.

Syntax

The syntax of the configuration option is as follows:

query-on address|interface [ port nnn|any|random ]

The port number is optional and if not present, the standard NTP port 123/UDP will be used. If port is present and a number is used that UDP port number will be used. The port number must not be a privileged port and it must not be used by other applications. If any is specified a non-privileged UDP port will be selected for you. If random is specified a random number will be specified for the UDP port and will be a non-privileged port.

Considerations

Remember that we can also get directives via ntpq and its :config directive.

We will need a way to "flush" the current query-on value(s).

There will be no command-line flag equivalent for the query-on directive.

• Does anybody have a compelling reason we should allow a command-line equivalent for the query-on directive?

There might be several logical networks on any given physical network interface. We should support a query-on address for each logical network. Do we need to do more than this?

There could well be Interesting routing and/or vlan cases we would want to consider as well.

Examples

  query-on 1.2.3.4 port 4123
  query-on 4.5.7.7
  query-on eth0 port any

Discussion and Comments

What is the difference between any and random - it is not clear to me.

We're talking about ports from 49152 through 65535, right? These are the Dynamic and/or Private ports.

-- HarlanStenn - 29 Mar 2009

The difference between any and random is that the O/S will provide a port number when you bind with the any option while random we generate a random number between 1024 and 65535 and use that. We are talking about the non-privileged ports between 1024 and 65535. There is no need to restrict further the available port number space.

-- DannyMayer - 29 Mar 2009

Danny, you deleted the query-on flush suggestion from the original.

Was that intentional?

-- HarlanStenn - 29 Mar 2009

My current thinking here is to have a separate command flushlist to differentiate from the actual command. Thus you could have the options:

flushlist query-on
flushlist listen-on

and then we would be able to add others to the list as necessary.

-- DannyMayer - 29 Mar 2009

OK, I think I prefer a flush keyword to the query-on and listen-on commands, as we might want to flush for a particular interface (for example).

Regardless, glad to see were in the same ballpark.

-- HarlanStenn - 30 Mar 2009