| Internet-Draft | de-eeas | January 2026 |
| Zhu | Expires 2 August 2026 | [Page] |
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.¶
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 2 August 2026.¶
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. 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.¶
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.¶
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.¶
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 EE DNS RR type is used to choose an alternative endpoint for the energy service by clients.¶
EE RRs have the same top-level format as other RRs[RFC1035]¶
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Name | / / / / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Type | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Class ^ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 1 The top-level format of EE RR¶
Where:¶
NAME: A <domain-name> which specifies a host.¶
TYPE: A new EE RR TYPE code with two octets is registered by IANA.¶
CLASS: Two octets contain one of the EE RR CLASS code.¶
TTL: A 32-bit signed integer that specifies the time inteval of the EE record cached before the source of the information should again be consulted.¶
RDLENGTH: An unsigned 16-bit integer between 0 and 65535 that specifies the length in octets of the RDATA field.¶
RDATA: A variable-length string of octets that describes the energy-related information.¶
The presentation format <RDATA> of the record [RFC1035] has the form:¶
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRIORITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ENAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EEPARAMS /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2 The format of the RDATA¶
Where:¶
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.¶
ENAME May be the domain name of either the alias target (for AliasMode) or the alternative endpoint (for ServiceMode).¶
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.¶
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.¶
A few initial EeParamKeys are defined here.¶
The "et" EeParamKey indicates the type of energy. The presentation value SHALL 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 SHALL be 4 bits in length.¶
The "pue" EeParamKey indicates the power usage effectiveness of the alternative data centers. The presentation value SHALL 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.¶
If ENAME has the value "." (represented in the wire format as a zero-length label), special rules apply.¶
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.¶
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.¶
"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:¶
Carry a domain name as $QNAME for query in the Question section.¶
Issue an EE query for $QNAME.¶
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.¶
If one or more ServiceMode records are returned, these represent the alternative endpoints. Sort the records by ascending PRIORITY.¶
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.¶
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.¶
When replying to an EE query, authoritative DNS servers SHOULD return A, AAAA, and EE records in the Additional section for any ENAME that is in the zone. If the zone is signed, the server SHOULD also include DNSSEC records in the Additional section whether the existence of these records or not.¶
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:¶
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.¶
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.¶
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.¶
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.¶
The EE RR type SHOULD be registered on the "Domain Name System (DNS) Parameters" page with a new code by IANA.¶
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.¶
This document should not affect the security of the Internet. [CHECK]¶
Thanks Aijun Wang for the template and help on this draft.¶