NTP DNS Resource Record

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.¶

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

[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.¶

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.¶

ntp.example.com. 300 IN NTP 1 . ntp-version=4,5

version           = 1*DIGIT *( "-" version-label )
version-label     = 1*( ALPHA / DIGIT )
ntp-version-value = version *( "," version )

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.¶

• 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

7. References

Acknowledgments

TODO acknowledge.¶

Author's Address