Internet DRAFT - draft-dnsop-eden-alias-rr-type
draft-dnsop-eden-alias-rr-type
DNSOP Working Group A. Eden
Internet-Draft DNSimple
Intended status: Standards Track March 29, 2017
Expires: September 30, 2017
Alias RR Type
draft-dnsop-eden-alias-rr-type-00
Abstract
This document describes a new DNS record type, ALIAS, which is used
by authoritative name servers to resolve a stored host name to its
corresponding A or AAAA records at request time.
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 September 30, 2017.
Copyright Notice
Copyright (c) 2017 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.
Eden Expires September 30, 2017 [Page 1]
Internet-Draft Alias RR Type March 2017
1. Introduction
1.1. Background and Motivation
DNS [RFC 1035] forbids the use of CNAME records on a node with other
records. It is common practice for web sites publish content on
their second-level domain name, and currently the only standards-
compliant way to acheive this is to use A and AAAA records on the
zone apex.
The challenge with this limitation is that service providers would
like to have flexibility over their network addressing but are
required to communicate any address changes to all customers and give
appropriate time for customers to update their DNS entries to ensure
a smooth transition to a new address space. As the number of
customers increases for a service provider, this approach becomes
increasingly difficult to manage and results in difficulties for both
the service provider and their customers.
The ALIAS record type (also known as ANAME or flattened CNAME)
provides a way for DNS managers to specify a hostname in their DNS
records which is then resolved to the correct A or AAAA records at
request time.
1.2. Terminology
"QTYPE" - The query type as defined in [RFC1035] and subsequent DNS
RFCs.
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 RFC 2119 [RFC2119].
2. The ALIAS Resource Record
Its RDATA is comprised of a single field, "target", which contains a
fully qualified domain name that MUST be sent in uncompressed form
[RFC1035]. The "target" field MUST be present. The presentation
format of "target" is that of a domain name [RFC1035].
The presentation format of the RR is as follows:
owner ttl class ALIAS target
An ALIAS record includes a TTL value that represents the maximum
time-to-live for a cached ALIAS record response in a resolver.
The ALIAS RDATA wire representation is only used for zone transfers.
Eden Expires September 30, 2017 [Page 2]
Internet-Draft Alias RR Type March 2017
3. Implementation
3.1. Resolution Guidelines
Authoritative name servers with support for ALIAS records MUST
support both A and AAAA materialization. When an authoritative name
server receives a request for a name, and the zone contains an ALIAS
record at that location, the authoritative name server MUST respond
as follows:
The server will respond with one or more A records (for a QTYPE A) or
one or more AAAA records (for a QTYPE AAAA) obtained by either: *
executing a recursive query for the ALIAS content or, * returning a
previously cached response.
If the recursive query returns an NXDOMAIN response, then the
authoritative name server MUST return an NXDOMAIN response as well.
If the recursive query fails, then the server MAY return a cached
response as long as the cache value is not older than the specified
TTL value.
3.2. TTL Calculation
As described in section [3.1] the ALIAS is stored with its own TTL
value. When an ALIAS is resolved to its corresponding A or AAAA
records, the authoritative name server MUST return the TTL from the
resolver response.
When the authoritative name server uses a cached value, it returns
the lower TTL value.
3.3. Handling CNAME QTYPE
Authoritative name servers that receive a CNAME request at a an ALIAS
node should treat the request as a QTYPE A.
Authoritative name servers that receive a CNAME request at an ALIAS
node MUST treat the request as a QTYPE A.
3.4. Handling ANY QTYPE
Authoritative name servers that receive an ANY request at an ALIAS
node SHOULD respond with any A and AAAA records materialized from the
ALIAS record.
Eden Expires September 30, 2017 [Page 3]
Internet-Draft Alias RR Type March 2017
4. Security Considerations
To function properly with DNSSEC-aware resolvers, authoritative name
servers MUST sign the materialized records produced by the ALIAS
resolution.
Implementors MAY either materialize A and AAAA records offline and
sign the resulting records at that time, or sign the resulting
materialized records at request time.
5. Privacy Considerations
There are no additional privacy concerns introduced by this document.
6. IANA Considerations
This document uses a new DNS RR type, ALIAS, whose value must be
allocated by IANA from the Resource Record (RR) TYPEs subregistry of
the Domain Name System (DNS) Parameters registry.
7. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Anthony Eden
DNSimple
Email: anthony.eden@dnsimple.com
URI: https://dnsimple.com/
Eden Expires September 30, 2017 [Page 4]