r8 - 2013-11-17 - 15:50:26 - FrankKardelYou are here: NTP >  Dev Web > DevelopmentIssues > QueryOn
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.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

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.

ALERT! This topic discusses a feature which may be added to a future release of NTP. This feature is not present in any current release of NTP.

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

You don't really need a flush for an interface since you can just append a new query-on option and that will override previous query-on options since the last one wins. You do need a flush option to clear the whole list which is why I'm proposing a separate flushlist option which will really only get used for reconfigurations.

-- DannyMayer - 30 Mar 2009

What about a system with multiple NICs? What about the case where, on a single NIC, a machine has different IPs on different subnets?

-- HarlanStenn - 2010-04-17

in my option 'query-on' does not go far enough. The peer local address handling needs to be modified so we can configure the local address preferences per peer association. Thus the peer/server/etc. statements should be able to take a query-address of auto|ip-addr|if-name. A default 'query-on' could give the default configuration for the local address selection.

-- FrankKardel - 2013-11-17

 
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback