DNS Extensions to Energy Efficiency as a Service(EEAS)
draft-zhu-dnsop-de-eeas-02
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 | Huahong Zhu | ||
| Last updated | 2026-04-20 | ||
| 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-zhu-dnsop-de-eeas-02
DNSOP Working Group H. Zhu, Ed.
Internet-Draft China Telecom
Obsoletes: TRUE (if approved) 20 April 2026
Intended status: Standards Track
Expires: 22 October 2026
DNS Extensions to Energy Efficiency as a Service(EEAS)
draft-zhu-dnsop-de-eeas-02
Abstract
This document describes a new Mechanism and DNS resource record (RR)
type to carry information about energy-related characteristics for
end-to-end internet access. The "EE" ("Energy Efficiency") record
allows the network to provide different levels of energy-saving
service. By providing more energy information to the client before
it attempts to establish a connection, these records offer potential
benefits to enhancements on energy as service criteria.
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 22 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhu Expires 22 October 2026 [Page 1]
Internet-Draft de-eeas April 2026
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The EE Record Definitions . . . . . . . . . . . . . . . . . . 3
2.1. EE Record Format . . . . . . . . . . . . . . . . . . . . 3
2.2. RDATA Format . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Interpretation . . . . . . . . . . . . . . . . . . . . . 4
2.3.1. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2. ENAME . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.3. EEPARAMS . . . . . . . . . . . . . . . . . . . . . . 5
2.3.4. Initial EeParamKeys . . . . . . . . . . . . . . . . . 5
3. "." in ENAME . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 6
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 7
5.1. Authoritative Servers . . . . . . . . . . . . . . . . . . 7
5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. EE RR Type . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. EEPARAMS Registry . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Energy savings and green communication are crucial due to the effects
of climate change and the global energy shortage. Today, users who
are more aware and sensitive toward environment may prefer reducing
their carbon footprint by choosing more renewable energy sources than
non-renewable sources for network services, even if it means
compromised service performance.
Zhu Expires 22 October 2026 [Page 2]
Internet-Draft de-eeas April 2026
With intended usage of renewable energy sources in the network, the
usage efficiency of energy consumption may be improved when resolving
domain-names by taking availability of renewable energy sources into
consideration. Overall reduction in energy usage and prioritizing
usage of renewable energy sources over non-renewable energy sources
need a coordinated solution at both user and application levels from
the perspective of end-to-end. DNS can play an important role in the
whole process. For example, authoritative servers can implement
energy-aware load balancing and scheduling functions based on energy-
related strategies. However, the exposure of the users' consent,
awareness, and energy-related information is necessary in this
context as it may result in dynamic service adjustment at flow level
based on energy. Thus, energy-aware Domain Name resolution with the
user's consent and awareness is the requirement for energy saving and
green energy usage.
To support Energy Efficiency as a service in the DNS, this document
defines the following extensions:
* The "EE" ("Energy Efficiency") record type is defined that can be
applied directly and efficiently to a wide range of services. The
information helps make connectivity decisions with low carbon
emissions by using more renewable energy source-operated servers.
* A mechanism is described how the "EE resolution" is performed by
the client and DNS servers. If a client learns more about the
origin energy before connecting (such as energy consumption,
energy supply mix, power usage effectiveness, and availability
conditions), it may be able to choose a greener endpoint without
degrading the service experience.
* The "EE" ("Energy Efficiency") record's compatibility with other
resource records is described.
1.1. Requirements Language
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.
2. The EE Record Definitions
2.1. EE Record Format
The EE DNS RR type is used to choose an alternative endpoint for the
energy service by clients.
Zhu Expires 22 October 2026 [Page 3]
Internet-Draft de-eeas April 2026
EE RRs have the same top-level format as other RRs[RFC1035]
2.2. RDATA Format
The presentation format <RDATA> of the record [RFC1035] has the form:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRIORITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ENAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EEPARAMS /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2 The format of the RDATA
Where:
* PRIORITY: An unsigned 16-bit integer that specifies the priority
of this record.
* ENAME: A <domain-name> which specifies a host of an alternative
endpoint.
* EEPARAMS: A <character-string> which specifies the energy
parameters of the alternative endpoint.
2.3. Interpretation
2.3.1. PRIORITY
RRsets are explicitly unordered collections, so the PRIORITY field
imposes an ordering on EE RRs. A smaller PRIORITY indicates that the
domain owner prefers the usage of this record to other RRs with a
larger PRIORITY value. A value of 0 indicates AliasMode. Other
values indicate Servicemode.
When receiving an RRset containing multiple EE records with the same
PRIORITY value, clients SHOULD apply a random shuffle within a
priority level to select the records to ensure uniform load
balancing.
2.3.2. ENAME
ENAME May be the domain name of either the alias target (for
AliasMode) or the alternative endpoint (for ServiceMode).
Zhu Expires 22 October 2026 [Page 4]
Internet-Draft de-eeas April 2026
In AliasMode, the EE record aliases a service to an ENAME. EE RRsets
SHOULD only have a single RR in AliasMode. If multiple AliasMode RRs
are present, either clients or recursive resolvers SHOULD pick one at
random.
In ServiceMode, the ENAME and EEPARAMS within each RR associate an
alternative endpoint for the service with its connection parameters.
2.3.3. EEPARAMS
EEPARAMS is a whitespace-separated list with each EEPARAM consisting
of an EeParamKey=EeParamValue pair. EeParamKey names are presented
by lowercase alphanumeric strings from the ranges "a"-"z" and
"0"-"9". Each EeParamKey SHALL appear at most once in the EEPARAMS.
EeParamKeys SHOULD be registered by IANA. EEPARAMS in presentation
format MAY appear in any order, but keys MUST NOT be repeated.
The EeParamValue is a character string. If the optional "=" and
EeParamValue are omitted, the value is interpreted as empty.
2.3.4. Initial EeParamKeys
A few initial EeParamKeys are defined here.
The "et" EeParamKey indicates the type of energy. The presentation
value MUST be a comma-separated list of one or more et-ids.
The "eei" EeParamKey indicates the Energy Efficiency Index of
alternative endpoints. The index of Energy Efficiency is defined
into five levels from 1 to 5. The presentation value MUST be 4 bits
in length.
The "pue" EeParamKey indicates the power usage effectiveness of the
alternative data centers. The presentation value MUST be a 2-octet
length.
The "v4addr" EeParamKey conveys IPv4 addresses used to reach the
endpoint to minimize additional connection latency by clients.
The "v6addr" EeParamKey conveys IPv6 addresses used to reach the
endpoint to minimize additional connection latency by clients.
3. "." in ENAME
If ENAME has the value "." (represented in the wire format as a zero-
length label), special rules apply.
Zhu Expires 22 October 2026 [Page 5]
Internet-Draft de-eeas April 2026
3.1. AliasMode
For AliasMode EE RRs, an ENAME of "." indicates that the service is
not available or does not exist. This indication is advisory:
clients encountering this indication MAY ignore it and attempt to
connect without EE.
3.2. ServiceMode
For ServiceMode EE RRs, if ENAME has the value ".", then the owner
name of this record MUST be used as the effective ENAME. If the
record has a wildcard owner name in the zone file, the recipient
SHALL use the response's synthesized owner name as the effective
ENAME.
4. Client Behavior
"EE resolution" is the process of enumerating and ordering the
available endpoints for a service, as performed by the client. EE
resolution is as follows:
1. Carry a domain name as $QNAME for query in the Question section.
2. Issue an EE query for $QNAME.
3. If an AliasMode EE record is returned, set $QNAME to its ENAME
and loop back to Step 2, subject to chain length limits and loop
detection heuristics.
4. If one or more ServiceMode records are returned, these represent
the alternative endpoints. Sort the records by ascending
PRIORITY.
5. Otherwise, EE resolution has failed, and the list of available
endpoints is empty.
This procedure does not rely on any recursive or authoritative DNS
server to comply with this specification or have any awareness of EE.
Clients MUST consider an RR malformed if:
* The end of the RDATA occurs within an EEPARAM.
* EeParamKeys are not in strictly increasing numeric order.
* The EeParamValue for an EeParamKey does not have the expected
format.
Zhu Expires 22 October 2026 [Page 6]
Internet-Draft de-eeas April 2026
Note that the second condition implies that there are no duplicate
EeParamKeys.
If any RRs are malformed, the client MUST reject the entire RRset and
fall back to non-EE connection establishment.
5. DNS Server Behavior
5.1. Authoritative Servers
When replying to an EE query, authoritative DNS servers SHOULD return
A, AAAA, and EE records in the Answer section for any ENAME that is
in the zone. If the zone is signed, the server SHOULD also include
DNSSEC records in the Answer section whether the existence of these
records or not.
5.2. Recursive Resolvers
Whether the recursive resolver is aware of EE or not, the normal
response construction process used for unknown RR types[RFC3597]
generates the Answer section of the response. If recursive resolvers
are aware of EE, they SHOULD help the client execute the procedure in
Section 4 with minimum overall latency by incorporating additional
valid information into the Additional section of the response as
follows:
1. Incorporate the results of EE resolution. If the recursive
resolver's local chain length limit (which may be different from
the client's limit) has been reached, terminate.
2. If any of the resolved EE record is in AliasMode, choose one of
them at random, and resolve EE, A, and AAAA records for its
ENAME.
* If any EE record is resolved, go to Step 1.
* Otherwise, incorporate the results of A and AAAA resolution,
and terminate.
3. All the resolved EE records are in ServiceMode. Resolve A and
AAAA queries for each ENAME (or for the owner name if ENAME is
"."), incorporate all the results, and terminate.
Zhu Expires 22 October 2026 [Page 7]
Internet-Draft de-eeas April 2026
In this procedure, "resolve" means processing a query for that set as
the resolver's ordinary recursive resolution procedure. This
includes following any alias that the resolver would ordinarily
follow (e.g., CNAME). Errors or anomalies inobtaining additional
records MAY cause this process to terminate, but they MUST NOT cause
the resolver to send a response about failure.
6. IANA Considerations
6.1. EE RR Type
The EE RR type SHOULD be registered on the "Domain Name System (DNS)
Parameters" page with a new code by IANA.
6.2. EEPARAMS Registry
The "Energy Efficiency Parameter Keys (EeParamKeys)" SHOULD be
registered in the "Domain Name System (DNS) Parameters" category of a
new page entitled "DNS Energy Efficiency (EE)" by IANA. This
registry defines the namespace for parameters, including string
representations and numeric EeParamKey values.
7. Security Considerations
This document should not affect the security of the Internet.
[CHECK]
8. References
8.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/info/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/info/rfc8174>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
Zhu Expires 22 October 2026 [Page 8]
Internet-Draft de-eeas April 2026
8.2. Informative References
Acknowledgements
Thanks Aijun Wang for the template and help on this draft.
Author's Address
Huahong Zhu (editor)
China Telecom
Zhongshan Avenue West
Guangzhou
Guangdong, 510630
China
Phone: 8613316097206
Email: zhuhh11@chinatelecom.cn
Zhu Expires 22 October 2026 [Page 9]