| Internet-Draft | EDNS TRACEPARENT | September 2026 |
| Lexis, et al. | Expires 21 March 2027 | [Page] |
This document defines a new EDNS Option named TRACEPARENT that is used to communicate an identifier for correlating events between DNS systems.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://PowerDNS.github.io/draft-edns-otel-trace-ids/draft-edns-otel-trace-ids.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-edns-otel-trace-ids/.¶
Source for this draft and an issue tracker can be found at https://github.com/PowerDNS/draft-edns-otel-trace-ids.¶
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 21 March 2027.¶
Copyright (c) 2026 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.¶
In distributed systems or otherwise interacting systems, operators might want to correlate events or know how an incoming request moves through the system. To achieve this correlation, a tracing identifier is generated on the front end system that receives the initial request and passed to downstream systems. These downstream systems will generate data related to the request that can be collected and used in system health measurements or trouble shooting.¶
This document defines a new EDNS[RFC6891] option (TRACEPARENT) to pass tracing identifiers between DNS servers. It follows the W3C recommendation for Trace Context and the traceparent HTTP header, version 00[W3C.trace-context].¶
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.¶
The TRACEPARENT option has the following wire format:¶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0: | OPTION-CODE (TBD1) |
+---------------+---------------+
2: | OPTION-LENGTH |
+---------------+---------------+
4: | VERSION | RESERVED |
+---------------+---------------+
6: | TRACEPARENT DATA /
+---------------+---------------+
¶
The VERSION field indicates how the TRACEPARENT DATA should be interpreted. This document defines the following versions:¶
| Version | Usage |
|---|---|
| 0 | Defined in this document |
| 252-255 | Private use |
The RESERVED field is for future expansion and MUST be set to 0.¶
The TRACEPARENT DATA field for version 0 contains 3 fields: a 16 byte trace-id, an 8 byte parent-id, and a 1 byte trace-flags field. All three fields MUST be present. Hence, for version 0, OPTION-LENGTH MUST be 27. An option with any other length, a non-zero RESERVED field, or an all-zero TRACE-ID or PARENT-ID is malformed.¶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0: | TRACE-ID /
/ |
+---------------+---------------+
16: | PARENT-ID /
/ |
+---------------+---------------+
24: | TRACEFLAGS |
+---------------+
¶
Even though EDNS options will never appear in DNS zone files, its value could appear in logging or analysis of packet captures.¶
The presentation format for TRACEPARENT version 0 follows the traceparent HTTP header from Section 3.2 of [W3C.trace-context]:¶
TRACEPARENT=[version]-[trace-id]-[parent-id]-[trace-flags]¶
Where each field is represented as Base16 with the hexadecimal characters in lowercase.¶
The presentation format for unknown and private versions is¶
TRACEPARENT=[version]-[traceparent-data]¶
Where each field is represented as Base16 with the hexadecimal characters in lowercase.¶
TRACEPARENT SHOULD only be used after mutual agreement between the sending and receiving nameserver operators. A nameserver MAY include a TRACEPARENT option in outgoing queries to trigger tracing in receiving servers. This model follows the recommendations of Section 4 of [W3C.trace-context].¶
Performing tracing SHOULD NOT alter DNS query processing in such a way that responses differ between queries sent with and without a TRACEPARENT option.¶
Nameservers receiving a malformed TRACEPARENT option SHOULD ignore this option and continue processing the query. This handling of the malformed option is the opposite of the definition in section 7 of [RFC6891].¶
It is RECOMMENDED to inform the operator of the nameserver, for example using logging, about malformed TRACEPARENT options. A nameserver MAY ignore TRACEPARENT options for any reason, including resource constraints.¶
A TRACEPARENT option MUST at most appear once in the OPT pseudo-record, multiple TRACEPARENT options MUST be considered malformed.¶
Tracing information is collected outside of the DNS transaction and is independent of the DNS query processing. The inclusion of a TRACEPARENT option in a query must be seen as a signal from the requester that tracing should be performed.¶
The TRACEPARENT option SHOULD NOT appear in responses from nameserver and it's inclusion in a response is not defined in this document.¶
It is RECOMMENDED to use access control on who can send TRACEPARENT to initiate data collection, e.g. using IP address allow-lists, TSIG[RFC8945], or other methods.¶
When a nameserver receives the TRACEPARENT EDNS option from a system that is allowed to initiate tracing, it should perform any operations required to collect tracing information, as configured by the operator.¶
When a nameserver receives the TRACEPARENT EDNS option from a system that is not allowed to initiate tracing, it MUST ignore the option and process the query as if no TRACEPARENT option were present.¶
Tracing could use significant system resources and hence should be limited. As described in Section 5 and Section 5.1, tracing should only be done after after mutual agreement and access controls should be used. Other limitations that could be implemented are load-based, where the nameserver decides whether to enable tracing based on the system load, or based on a probability factor.¶
IANA is requested to assign a new value in the DNS EDNS0 Option Codes (OPT) [RFC6891] registry as follows:¶
| Value | Name | Status | Reference |
|---|---|---|---|
| TBD1 | TRACEPARENT | Optional | This document |
An OpenTelemetry Trace ID of 1234567890ABCDEF1234567890ABCDEF, Parent ID of FEDCBA0987654321, and no Trace Flags is presented as:¶
TRACEPARENT=00-1234567890abcdef1234567890abcdef-fedcba0987654321-00¶
The authors would like to acknowledge Job Snijders and Wouter de Vries for their initial ideas and expertise of OpenTelemetry.¶