Address-specific DNS aliases (ANAME)
draft-ietf-dnsop-aname-04
DNS Operations T. Finch
Internet-Draft University of Cambridge
Intended status: Standards Track E. Hunt
Expires: January 9, 2020 ISC
P. van Dijk
PowerDNS
A. Eden
DNSimple
W. Mekking
ISC
July 8, 2019
Address-specific DNS aliases (ANAME)
draft-ietf-dnsop-aname-04
Abstract
This document defines the "ANAME" DNS RR type, to provide similar
functionality to CNAME, but only for address queries. Unlike CNAME,
an ANAME can coexist with other record types. The ANAME RR allows
zone owners to make an apex domain name into an alias in a standards
compliant manner.
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 January 9, 2020.
Copyright Notice
Copyright (c) 2019 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 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
1.1. Overview
1.2. Terminology
2. The ANAME resource record
2.1. Presentation and wire format
2.2. Coexistence with other types
3. Substituting ANAME sibling address records
4. ANAME processing by primary masters
4.1. Zone transfers
4.2. DNSSEC
4.3. TTLs
5. ANAME processing by resolvers
6. Query processing
6.1. Authoritative servers
6.1.1. Address queries
6.1.2. ANAME queries
6.2. Resolvers
6.2.1. Address queries
6.2.2. ANAME queries
7. IANA considerations
8. Security considerations
9. Acknowledgments
10. Changes since the last revision
10.1. Version -04
10.2. Version -03
10.3. Version -02
11. References
11.1. Normative References
11.2. Informative References
11.3. URIs
Appendix A. Implementation status
Appendix B. Historical note
Appendix C. On preserving TTLs
C.1. Query bunching
C.2. Upstream caches
C.3. ANAME chains
C.4. ANAME substitution inside the name server
C.5. TTLs and zone transfers
Appendix D. Alternative setups
D.1. Reducing query volume
D.2. Zone transfer scalability
D.3. Tailored responses
Appendix E. ANAME loops
Authors' Addresses
1. Introduction
It can be desirable to provide web sites (and other services) at a
bare domain name (such as "example.com") as well as a service-
specific subdomain ("www.example.com").
If the web site is hosted by a third-party provider, the ideal way to
provision its name in the DNS is using a CNAME record, so that the
third party provider retains control over the mapping from names to
IP address(es). It is now common for name-to-address mappings to be
highly dynamic, dependent on client location, server load, etc.
However, CNAME records cannot coexist with other records with the
same owner name. (The reason why is explored in Appendix B). This
restriction means they cannot appear at a zone apex (such as
"example.com") because of the SOA, NS, and other records that have to
be present there. CNAME records can also conflict at subdomains, for
example, if "department.example.edu" has separately hosted mail and
web servers.
Redirecting website lookups to an alternate domain name via SRV or
Show full document text