Internet DRAFT - draft-bortzmeyer-bundled-signaling-alias

draft-bortzmeyer-bundled-signaling-alias







Network Working Group                                      S. Bortzmeyer
Internet-Draft                                                     AFNIC
Intended status: Informational                         November 14, 2016
Expires: May 18, 2017


        Signaling that a domain name is an alias of another one
              draft-bortzmeyer-bundled-signaling-alias-00

Abstract

   This document suggests a light-weight and semantics-free way to
   signal, in the DNS itself, that a domain name is actually an alias of
   another one (and therefore that they are member of the same bundle).

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   dnsbundled maiing list <https://www.ietf.org/mailman/listinfo/
   bundled-domain-names>.  The source of the document, as well as a list
   of open issues, is currently kept at Github [1].

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 http://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 May 18, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://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



Bortzmeyer                Expires May 18, 2017                  [Page 1]

Internet-Draft               Signaling alias               November 2016


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and background . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The ALIAS RR type . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Reverse aliasing  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Deployability . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION   5
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   5
     10.2.  Informative References . . . . . . . . . . . . . . . . .   5
     10.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  A TXT alternative to the new RR type . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction and background

   There are often requests that a domain name be regarded as a mere
   alias for another one, so it can be substituted by this another
   domain.  The reasons to do so are many
   [I-D.yao-bundled-name-problem-statement] and not discussed here.

   The problem is much more complicated than it seems and it is
   difficult to imagine a solution that will satisfy every use case.  We
   do not attempt to define such a solution.  Instead, we choose the
   path of least resistance and propose just to signal, in the DNS, this
   "aliasing" relationship.  This signaling is not accompanied by a
   specification of the semantics of this relationship, and this is a
   deliberate design decision.

   Existing solutions are insufficient: CNAMEs ([RFC1034], section
   3.6.2) only alias one domain name, not a subtree, and cannot be at
   the apex of a domain, where most people would want it (TODO
   Cloudflare article).  DNAMEs ([RFC6672]) alias a subtree but not the
   owner name, only its subdomains.  BNAMEs ([I-D.yao-dnsext-bname]) are
   not yet standardized and raise several issues (TODO describe).







Bortzmeyer                Expires May 18, 2017                  [Page 2]

Internet-Draft               Signaling alias               November 2016


1.1.  Terminology

   "Client": any program that will act on the basis of the DNS
   information described in this document.

   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].

2.  The ALIAS RR type

   We define a new RR type, ALIAS.  Its owner name is the apex of a
   domain, and its RDATA is the name of the domain which is
   substitutable to this one.  For instance, this says that foo.example
   is actually an alias of bar.example:

   $ORIGIN foo.example.
   @       IN  ALIAS bar.example.

   TODO formal presentation format

   TODO binary format

   The new RR type has no special processing requirment.  An
   authoritative name server MAY send it in the additional section of a
   response, when the QNAME is a domain name which has such an ALIAS.

   An alternative to a new record type is described in Appendix A.

3.  Usage

   The alias is for a subtree, that's why it is always at the apex of a
   domain.  TODO what if there is a subdelegation?

   The general idea is that clients will use this aliasing information
   as they please.  By "clients", we mean any program using this DNS
   resource record.  It can be a Web browser trying to visit a site, an
   EPP server trying to determine if a transfer is possible (or if it
   would break a bundle), a HTTP server trying to find out the list of
   values it will accept in the Host: header, etc.

   This lack of semantics is a deliberate feature; there are so many use
   cases for "bundled" domain names that it is difficult, at the present
   time, to design a solution to satisfy them all.  We therefore limit
   ourselves to signaling an intent, not to specify what to do with it.






Bortzmeyer                Expires May 18, 2017                  [Page 3]

Internet-Draft               Signaling alias               November 2016


4.  Reverse aliasing

   Some persons may want to have "reverse aliasing", either to easily
   find out the domains aliasing to them, or to "authorize" the
   aliasing.  (It is not clear yet if it is a good idea.  In the current
   DNS, decentralized and loosely coupled, nothing prevents someone to
   point a CNAME at you, and you cannot even know it.)

   To do so, we define a second RR type, SAILA, to specify a domain
   pointing at you:

   $ORIGIN bar.example.
   @       IN  SAILA foo.example.

5.  Deployability

   Because this document does not change the behavior of the name
   servers (either recursive or authoritative), it can be deployed on
   the existing infrastructure, providing name servers and DNS
   provisioning systems follow [RFC3597].  If they don't, the
   alternative in Appendix A may be considered.

   Adding this aliasing information to the DNS is extremely cheap and
   without any drawbacks.  The author hope it will be done, even without
   waiting clients that wil consume this information.

   It remains to be seen if it will be easier to upgrade the clients (to
   use this information) or the name servers (which is a requirment of
   other proposals like BNAME [I-D.yao-dnsext-bname]).

6.  IANA Considerations

   TODO register one (or two new RR types).

7.  Security Considerations

   No DNS security issues are expected since no specific action is
   mandated for the client.

   A client is responsible of what it decides to do with the aliasing
   information.

   A security-conscious client MAY decide to act on this aliasing
   information only if it is validated with DNSSEC.







Bortzmeyer                Expires May 18, 2017                  [Page 4]

Internet-Draft               Signaling alias               November 2016


8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   No implementation known at this time.

9.  Acknowledgments

   Thanks to the "Sichuan house" restaurant in Seoul for a nice place to
   start the discussion, and to CNNIC for the invitation.

10.  References

10.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

10.2.  Informative References

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
              2003, <http://www.rfc-editor.org/info/rfc3597>.




Bortzmeyer                Expires May 18, 2017                  [Page 5]

Internet-Draft               Signaling alias               November 2016


   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
              <http://www.rfc-editor.org/info/rfc6672>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <http://www.rfc-editor.org/info/rfc7942>.

   [I-D.yao-dnsext-bname]
              Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name
              Redirection", draft-yao-dnsext-bname-06 (work in
              progress), May 2016.

   [I-D.yao-bundled-name-problem-statement]
              Yao, J., Lee, X., and J. Levine, "Problem Statement for
              Fully Mapping One Name to Another Name", draft-yao-
              bundled-name-problem-statement-03 (work in progress),
              October 2016.

10.3.  URIs

   [1] https://github.com/bortzmeyer/ietf-signaling-alias

Appendix A.  A TXT alternative to the new RR type

   In theory, a new RR type such as ALIAS works everywhere, thanks to
   [RFC3597].  In practice, while most name servers won't have any
   problem with it, many domain name provisioning systems will have
   trouble handling ALIAS.  Therefore, we suggest here an alternative: a
   TXT record under the subdomain _alias.  The example above would
   become:

   $ORIGIN foo.example.
   _alias  IN  TXT bar.example.

   TODO IAB RFC on the proper use of TXT records

Author's Address












Bortzmeyer                Expires May 18, 2017                  [Page 6]

Internet-Draft               Signaling alias               November 2016


   Stephane Bortzmeyer
   AFNIC
   1, rue Stephenson
   Montigny-le-Bretonneux  78180
   France

   Phone: +33 1 39 30 83 46
   Email: bortzmeyer+ietf@nic.fr
   URI:   http://www.afnic.fr/










































Bortzmeyer                Expires May 18, 2017                  [Page 7]