Internet-Draft EDNS TRACEPARENT February 2026
Moerbeek, et al. Expires 27 August 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-edns-otel-trace-ids-latest
Published:
Intended Status:
Informational
Expires:
Authors:
O. Moerbeek
PowerDNS.com B.V.
P. V. Dijk
PowerDNS.com B.V.
P. Lexis
PowerDNS.com B.V.

Communicating Distributed Trace IDs in EDNS

Abstract

This document defines a new EDNS Option named TRACEPARENT that is used to communicate an identifier for correlating events between DNS systems.

About This Document

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.

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 27 August 2026.

Table of Contents

1. Introduction

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 Recommendation: Trace Context].

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. Wire Format

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:

Table 1
Version Usage
0 Defined in this document
252-255 Private use

The RESERVED field is for future expansion and MUST be set to 0.

3.1. Version 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 these fields are MANDATORY.

       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   |
      +---------------+

4. Presentation Format

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 Recommendation: 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.

5. Processing of TRACEPARENT

TRACEPARENT SHOULD only be used after mutual agreement between the upstream and downstream server operators. A nameserver MAY include a TRACEPARENT option in outgoing queries to trigger tracing in downstream servers. This model follows the recommendations of Section 4 of [W3C Recommendation: Trace Context].

Performing tracing SHOULD NOT impact DNS query processing. Hence, nameservers receiving a malformed TRACEPARENT option SHOULD ignore this option and continue processing the query. It is RECOMMENDED to inform the operator of the nameserver, for example using logging, about malformed TRACEPARENT options. An nameserver MAY ignore TRACEPARENT options for any reason, including resource constraints.

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.

5.1. Access Control

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.

6. Security Considerations

TODO Security

7. IANA Considerations

None.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC6891]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, , <https://www.rfc-editor.org/rfc/rfc6891>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8945]
Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, , <https://www.rfc-editor.org/rfc/rfc8945>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/rfc/rfc9499>.
[W3C Recommendation: Trace Context]
"Trace Context", W3C WD trace-context, W3C trace-context, <https://www.w3.org/TR/trace-context/>.

Appendix A. Presentation Format Examples

An OpenTelemetry Trace ID of 1234567890ABCDEF1234567890ABCDEF, Parent ID of FEDCBA0987654321, and no Trace Flags is presented as:

TRACEPARENT=00-1234567890abcdef1234567890abcdef-fedcba0987654321-00

Acknowledgments

The authors would like to acknowledge Job Snijders and Wouter de Vries for their initial ideas and expertise of OpenTelemetry.

Authors' Addresses

Otto Moerbeek
PowerDNS.com B.V.
Peter van Dijk
PowerDNS.com B.V.
Pieter Lexis
PowerDNS.com B.V.