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]
