DNSOP Working Group H. Zhu, Ed. Internet-Draft China Telecom Intended status: Standards Track 29 January 2026 Expires: 2 August 2026 DNS Extensions to Energy Efficiency as Service(EEAS) draft-zhu-dnsop-de-eeas-00 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 2 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Zhu Expires 2 August 2026 [Page 1] Internet-Draft de-eeas January 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 . . . . . . . . . . . . . . . . . . . . . 5 2.3.1. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2. ENAME . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.3. EEPARAMS . . . . . . . . . . . . . . . . . . . . . . 6 2.3.4. Initial EeParamKeys . . . . . . . . . . . . . . . . . 6 3. "." in ENAME . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 7 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 5. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 8 5.1. Authoritative Servers . . . . . . . . . . . . . . . . . . 8 5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. EE RR Type . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. EEPARAMS Registry . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 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 2 August 2026 [Page 2] Internet-Draft de-eeas January 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 2 August 2026 [Page 3] Internet-Draft de-eeas January 2026 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 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. 2.2. RDATA Format The presentation format of the record [RFC1035] has the form: Zhu Expires 2 August 2026 [Page 4] Internet-Draft de-eeas January 2026 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 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 which specifies a host of an alternative endpoint. * EEPARAMS: A 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). 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. Zhu Expires 2 August 2026 [Page 5] Internet-Draft de-eeas January 2026 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 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. 3. "." in ENAME If ENAME has the value "." (represented in the wire format as a zero- length label), special rules apply. 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. Zhu Expires 2 August 2026 [Page 6] Internet-Draft de-eeas January 2026 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. 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. Zhu Expires 2 August 2026 [Page 7] Internet-Draft de-eeas January 2026 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 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. 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. 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 Zhu Expires 2 August 2026 [Page 8] Internet-Draft de-eeas January 2026 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, . 8.2. Informative References Acknowledgements Thanks Aijun Wang for the template and help on this draft. Author's Address Zhu Expires 2 August 2026 [Page 9] Internet-Draft de-eeas January 2026 Huahong Zhu (editor) China Telecom Zhongshan Avenue West Guangzhou Guangdong, 510630 China Phone: 8613316097206 Email: zhuhh11@chinatelecom.cn Zhu Expires 2 August 2026 [Page 10]