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.

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 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
• 1.1. Terminology
• 2. The ALIAS RR type
• 3. Usage
• 4. Reverse aliasing
• 5. Deployability
• 6. IANA Considerations
• 7. Security Considerations
• 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
• 9. Acknowledgments
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A. A TXT alternative to the new RR type
• Author's Address

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

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

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

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:

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.

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

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

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

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.

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

10.2. Informative References

Appendix A. A TXT alternative to the new RR type

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

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:

Author's Address