Relative Labels in the Domain Name System
draft-yocto-dns-relative-label-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Ben van Hartingsveldt
Last updated 2024-07-21
RFC stream (None)
Formats
txt html xml htmlized bibtex bibxml
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)
Email authors IPR References Referenced by Nits Search email archive
draft-yocto-dns-relative-label-00 
Network Working Group                             B.J. van Hartingsveldt
Internet-Draft                                                     Yocto
Intended status: Informational                              21 July 2024
Expires: 22 January 2025

               Relative Labels in the Domain Name System
                   draft-yocto-dns-relative-label-00

Abstract

   This document defines a new DNS Label Type using the Extension
   Mechanisms for DNS to indicate when a relative domain name is used.

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 January 2025.

Copyright Notice

   Copyright (c) 2024 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.

van Hartingsveldt        Expires 22 January 2025                [Page 1]
Internet-Draft             DNS Relative Labels                 July 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Label Format  . . . . . . . . . . . . . . . . . . . . . . . .   2
     4.1.  Wire format . . . . . . . . . . . . . . . . . . . . . . .   2
     4.2.  Representation format . . . . . . . . . . . . . . . . . .   3
     4.3.  Canonical Representation and Sort Order . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   This document defines a "Relative Label" which may appear within
   domain names.  This new label type enables resource records to be
   stored with their relative form (e.g. "www" instead of
   "www.example.com.").

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Motivation

   Relative labels are intended to efficiently solve the problem of
   using FQDNs when a relative label is wanted.  For example, when
   someone wants to add the MX record "0 mx" instead of "0
   mx.example.com." using DNS UPDATE [RFC2136].  It is also useful for
   DNS providers that store all the records in binary format.  Saving
   data in binary requires less space and the data is already in wire
   format, but at the moment there is no way to save relative domains.

4.  Label Format

   Relative labels can only appear in the end of a relative FQDN, like
   the zero octet only appears in the end of an absolute FQDN.  Message
   compression is possible when also using the relative label, but
   because the relative label already gives the possibility to leave out
   the zone name, message compression will likely have less effect.

4.1.  Wire format

van Hartingsveldt        Expires 22 January 2025                [Page 2]
Internet-Draft             DNS Relative Labels                 July 2024

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0 1|    ELT    |
   +-+-+-+-+-+-+-+-+

                                  Figure 1

   ELT  000000 binary, the six-bit extended label type [RFC2671]
      assigned to the Relative Label.

4.2.  Representation format

   As described in [RFC1035], relative domain names are domain names
   that don't end with a dot.

4.3.  Canonical Representation and Sort Order

   Before records are sorted for DNSSEC [RFC2065] purposes, the resource
   record MUST be converted to canonical form.  This simply happens by
   replacing the relative label by the whole zone name.  Also, the
   relative label should not appear when doing queries, except for AXFR
   and IXFR.

5.  IANA Considerations

   This document defines one Extended Label Type, termed the Relative
   Label, and requests registration of the code point 000000 binary in
   the space defined by [RFC2671].

6.  Security Considerations

   All security considerations which apply to traditional ASCII DNS
   labels apply equally to binary labels.  The canonicalization and
   sorting rules of section 3.3 allow these to be addressed by DNS
   Security [RFC2065].

7.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", RFC 1035, DOI 10.17487/RFC1035, November
              1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC2065]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2065, DOI 10.17487/RFC2065, January 1997,
              <https://www.rfc-editor.org/rfc/rfc2065>.

van Hartingsveldt        Expires 22 January 2025                [Page 3]
Internet-Draft             DNS Relative Labels                 July 2024

   [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/rfc/rfc2119>.

   [RFC2136]  Vixie, P., "Dynamic Updates in the Domain Name System (DNS
              UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/rfc/rfc2136>.

   [RFC2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)",
              RFC 2119, DOI 10.17487/RFC2671, August 1999,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Author's Address

   B.J. van Hartingsveldt
   Yocto
   Email: ben.vanhartingsveldt@yocto.com

van Hartingsveldt        Expires 22 January 2025                [Page 4]