]> independent

minami.hiroy@gmail.com

Internet Network Time Protocols internet-draft This document defines a new NTP DNS Resource Record, similar in concept to the HTTPS DNS Resource Record specified in . This record enables an NTP server to indicate, via DNS, the versions of the NTP protocol it supports prior to the initiation of any NTP message exchange. Discussion Venues Discussion of this document takes place on the Network Time Protocols Working Group mailing list (ntp@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction is currently under standardization, and there are concerns regarding how clients select the newer NTP protocol version to use. The server will drop NTP packets with unsupported versions. Therefore, clients need to select an NTP version that the server can receive; however, clients have no reliable way to know the server’s supported versions in advance. Accordingly, clients commonly initiate communication using NTPv4, assuming that NTPv4 is supported by the server, even if the server also implements NTPv5. Servers then attempt to advertise NTPv5 support to clients using the NTPv4 reference timestamp. The version of NTP used in the first request is therefore effectively based on implicit assumptions rather than explicit information. This creates challenges for the deployment of future NTP protocol versions. To address this challenge, this document defines a DNS-based mechanism similar to the HTTPS Resource Record (). This mechanism enables a server to advertise the NTP protocol versions it supports before a client initiates any NTP communication.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

NTP Resource Record The NTP Resource Record (RR type code TBD) is a SVCB-compatible RR type, as defined in . It uses the same RDATA wire format as the SVCB RR, but its semantics are specialized for discovery and configuration of Network Time Protocol (NTP) services.

Example The following example illustrates the presentation format of the NTP RR, showing how a server advertises support for multiple NTP protocol versions using the ntp-version SvcParamKey.

ntp-version SvcParams The ntp-version SvcParamKey indicates the set of NTP protocol versions supported by the service endpoint. Its value is a comma-separated list of ASCII version identifiers. Each version identifier consists of a numeric version number, optionally followed by a hyphen and an alphanumeric label (e.g., “5-draft5”), allowing servers to indicate support for development, experimental, or otherwise distinguished variants of a protocol version. ABNF: The wire-format consists of one or more version identifiers, each encoded as a length-prefixed byte sequence. These length–value pairs are concatenated to form the SvcParamValue.

nts SvcParams ( Is it useful to define nts SvcParams to indicate NTS support? )

Operational Sequence and Client Behavior The following list outlines the typical operational flow for deploying and using the NTP Resource Record, from server-side configuration to client-side version selection and communication. In practice, clients MAY perform NTP RR resolution in parallel with their default NTP initiation behavior (typically NTPv4, or NTPv5 when configured) and use the result when available.

• The server operator publishes an NTP RR in the authoritative DNS zone, including the appropriate SvcParams such as ntp-version="4,5".
• The client initiates DNS resolution for the NTP RR corresponding to the target domain name; if the NTP RR is not available, the client falls back to its default behavior (typically NTPv4).
• The client processes the DNS response using the rules for SVCB-compatible RR types.
  • If the response is in AliasMode (SvcPriority = 0), the client follows the alias target and repeats resolution.
  • If the response is in ServiceMode, the client proceeds to evaluate the associated SvcParams.
• The client parses known SvcParams; unknown parameters are ignored.
• If the ntp-version SvcParamKey is present, the client parses its value into a list of supported version identifiers.
• The client determines the intersection between its locally supported NTP versions and the versions listed in the ntp-version SvcParam.
• The client selects the highest mutually supported version and uses it as the version for the initial NTP request.
• If no mutually supported version exists, or if the NTP RR or its parameters are malformed, the client falls back to its default behavior (typically initiating communication using NTPv4).
• The client sends the first NTP request using the selected version.
• The server accepts the packet if the version is supported; packets using unsupported versions are dropped according to normal NTP behavior.
• NTP communication proceeds using the selected protocol version.

Security Considerations TODO

IANA Considerations

NTP RR Type TODO

References Normative References This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d.

Acknowledgments TODO acknowledge.