NTP DNS Resource Record
draft-yuki-ntp-dns-record-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Yuki Goto | ||
| Last updated | 2025-11-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yuki-ntp-dns-record-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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, <https://www.rfc-editor.org/rfc/rfc9460>.
7.2. Informative References
[NTPv5] "Network Time Protocol Version 5", Work in Progress,
Internet-Draft, draft-ietf-ntp-ntpv5-07, n.d.,
<https://datatracker.ietf.org/doc/html/draft-ietf-ntp-
ntpv5-07>.
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]