Network Time Protocols 後藤ゆき (Y. Goto) Internet-Draft independent Intended status: Informational 24 November 2025 Expires: 28 May 2026 NTP DNS Resource Record draft-yuki-ntp-dns-record-00 Abstract This document defines a new NTP DNS Resource Record, similar in concept to the HTTPS DNS Resource Record specified in [RFC9460]. 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 This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Time Protocols Working Group mailing list (ntp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ntp/. Source for this draft and an issue tracker can be found at https://github.com/flano-yuki/draft-yuki-ntp-dns-rr-. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 May 2026. Goto Expires 28 May 2026 [Page 1] Internet-Draft NTP DNS Resource Record November 2025 Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. NTP Resource Record . . . . . . . . . . . . . . . . . . . . . 3 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. ntp-version SvcParams . . . . . . . . . . . . . . . . . . 3 3.3. nts SvcParams . . . . . . . . . . . . . . . . . . . . . . 4 4. Operational Sequence and Client Behavior . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1. NTP RR Type . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [NTPv5] 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. Goto Expires 28 May 2026 [Page 2] Internet-Draft NTP DNS Resource Record November 2025 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 ([RFC9460]). This mechanism enables a server to advertise the NTP protocol versions it supports before a client initiates any NTP communication. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. NTP Resource Record The NTP Resource Record (RR type code TBD) is a SVCB-compatible RR type, as defined in [RFC9460]. 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. 3.1. 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.example.com. 300 IN NTP 1 . ntp-version=4,5 3.2. 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: version = 1*DIGIT *( "-" version-label ) version-label = 1*( ALPHA / DIGIT ) ntp-version-value = version *( "," version ) Goto Expires 28 May 2026 [Page 3] Internet-Draft NTP DNS Resource Record November 2025 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. 3.3. nts SvcParams ( Is it useful to define nts SvcParams to indicate NTS support? ) 4. 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. Goto Expires 28 May 2026 [Page 4] Internet-Draft NTP DNS Resource Record November 2025 * 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. 5. Security Considerations TODO 6. IANA Considerations 6.1. NTP RR Type TODO 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . 7.2. Informative References [NTPv5] "Network Time Protocol Version 5", Work in Progress, Internet-Draft, draft-ietf-ntp-ntpv5-07, n.d., . Goto Expires 28 May 2026 [Page 5] Internet-Draft NTP DNS Resource Record November 2025 Acknowledgments TODO acknowledge. Author's Address Yuki Goto independent Email: minami.hiroy@gmail.com Additional contact information: 後藤ゆき independent Goto Expires 28 May 2026 [Page 6]