



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]
