draft-ietf-dnsop-aname-02.txt

Network Working Group                                            E. Hunt
Internet-Draft                                                       ISC
Intended status: Standards Track                             P. van Dijk
Expires: August 13, 2018                                        PowerDNS
                                                                 A. Eden
                                                                DNSimple
                                                        February 9, 2018


             Address-specific DNS Name Redirection (ANAME)
                       draft-ietf-dnsop-aname-02

Abstract

   This document defines the "ANAME" DNS RR type, to provide similar
   functionality to CNAME, but only redirects type A and AAAA queries.
   Unlike CNAME, an ANAME can coexist with other record types.  The
   ANAME RR allows zone owners to redirect queries for apex domain names
   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 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 August 13, 2018.

Copyright Notice

   Copyright (c) 2018 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



Hunt, et al.             Expires August 13, 2018                [Page 1]

Internet-Draft                    aname                    February 2018


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The ANAME Resource Record . . . . . . . . . . . . . . . . . .   4
   3.  Authoritative Server Behavior . . . . . . . . . . . . . . . .   4
     3.1.  Address records returned with ANAME . . . . . . . . . . .   5
     3.2.  Coexistence with other types  . . . . . . . . . . . . . .   6
     3.3.  DNSSEC signing  . . . . . . . . . . . . . . . . . . . . .   6
   4.  Recursive Server Behavior . . . . . . . . . . . . . . . . . .   8
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Websites hosted by content distribution networks are often served by
   multiple IP addresses handling different geographic areas.  In many
   cases, an initial query for a domain name returns a CNAME record
   whose <target> is a name served by the CDN, and which ultimately
   resolves to a different final answer depending on the client's IP
   address or subnet, geographic location, or other considerations.

   It is common practice for websites to publish content at their
   registered domain name (sometimes referred to as a "bare domain" or
   "zone apex": for example, "example.com" rather than
   "www.example.com").  However, [RFC1033] forbids the use of CNAME
   records at the same node as any other record type.  Zone apex nodes
   always contain SOA and NS RRsets, and frequently contain other types
   such as DNSKEY, MX, TXT/SPF, etc.  Consequently, a CNAME record is
   not permitted at zone apex nodes.

   It should be noted that [RFC4034] relaxed this restriction by
   allowing coexistence of CNAME with RRSIG and NSEC records, but such
   exceptions are not applicable to other resource records.  RRSIG and
   NSEC exist to prove the integrity of the CNAME record; they are not
   intended to associate arbitrary data with the domain name.



Hunt, et al.             Expires August 13, 2018                [Page 2]

Internet-Draft                    aname                    February 2018


   DNAME [RFC6672] is also not a solution, as its function is to
   redirect all names in the namespace below the DNAME <owner>, not the
   DNAME <owner> itself.

   Redirecting website lookups to an alternate domain name via SRV or
   URI resource records would be an effective solution, but to date this
   approach has not been accepted by browser implementations.  In
   addition, it is not possible to use SRV records with wildcard names.

   As a result of the above, the only widely supported and standards-
   compliant way to publish content at a zone apex is to to place A and/
   or AAAA records at that node.  The flexibility afforded by CNAME is
   not available.

   This document specifies a new RR type "ANAME", which provides similar
   functionality to CNAME, but only for address queries (i.e., for type
   A or AAAA).  The ANAME record can be present at any DNS node, and can
   coexist with most other RR types, enabling it to be present at a zone
   apex, or any other place where the presence of other records prevents
   the use of CNAME.

   Authoritative servers configured with ANAME records will answer
   address queries for the ANAME owner with addresses found at the
   ANAME's target, and also with the ANAME itself.  Recursive resolvers
   which understand ANAME can re-query for the ANAME target, just as if
   they had received a CNAME response.  Recursive resolvers which do not
   understand ANAME will ignore the ANAME and consume the provided A/
   AAAA records directly.

   Similar authoritative functionality has been implemented and deployed
   by a number of DNS software vendors and service providers, using
   names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top
   level redirection.  These approaches have all been standards-
   noncompliant in one way or another, and none have provided a
   mechanism for a recursive resolver to follow the redirection chain
   itself.

1.1.  Terminology

   "Address type" refers to a DNS RR type that encodes a network
   address.  Currently the set of address types consists of A and AAAA.
   (This is not meant to be an exclusive list: in the event that any new
   address types are standardized in the future, this specification will
   cover them as well.)

   "Address query" refers to a DNS query for any address type.





Hunt, et al.             Expires August 13, 2018                [Page 3]

Internet-Draft                    aname                    February 2018


   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 ANAME Resource Record

   This document defines the "ANAME" DNS resource record type, with RR
   TYPE value [TBD].

   The ANAME presentation format is identical to that of CNAME
   [RFC1033]:

       owner ttl class ANAME target

   The wire format is also identical to CNAME, except that name
   compression is not permitted in ANAME RDATA, per [RFC3597].

   Only one ANAME <target> can be defined per <owner>.  An ANAME RRset
   MUST NOT contain more than one resource record.

3.  Authoritative Server Behavior

   When an ANAME record is present at a DNS node and a query is received
   by an authoritative server for type A or AAAA, the authoritative
   server MUST return the ANAME RR in the answer section.

   Because not all querying resolvers will understand ANAME, the
   authoritative server MUST also return address records, as described
   below, if it is able to retrieve them.  This is conceptually similar
   to the synthesized CNAME record included with DNAME responses
   [RFC6672].

   Authoritative servers implementing ANAME MUST be equipped to resolve
   the ANAME <target> on the querying resolver's behalf, either by
   sending queries to an external caching resolver or by implementing
   recursive resolution logic and a DNS cache internally, so that
   address records can be expanded when the ANAME <target> is in a
   separate zone from <owner>.

   If a query for the ANAME <target> returns a chaining response (i.e.,
   CNAME, DNAME, or another ANAME), then the authoritative server (or
   the resolver tasked with resolving the ANAME <target> on its behalf)
   MUST attempt to follow the chain until it is able to resolve a final
   address response, or until resolution fails.  However, the
   intermediate ANAMEs, CNAMEs, and DNAMEs encountered during this
   resolution process MUST NOT be included in the final response
   returned to the client.




Hunt, et al.             Expires August 13, 2018                [Page 4]

Internet-Draft                    aname                    February 2018


3.1.  Address records returned with ANAME

   If the original query is for type A, and an RRset of type A exists at
   the final ANAME <target>, then that A RRset (with <owner> changed to
   match that of the ANAME RR), MUST be appended to the answer section
   after the ANAME RRset.  If an AAAA RRset is also known to exist at
   the ANAME <target>, then the AAAA RRset MAY be appended to the
   additional section (again, with <owner> changed to match that of the
   ANAME RR).

   Similarly, if the original query was for type AAAA, and an AAAA RRset
   exists at the final ANAME <target>, then it is appended to the answer
   section (with <owner> changed).  If an A RRset also exists at the
   final ANAME <target> then it MAY be appended to the additional
   section.

   If the address type originally queried is not present at the ANAME
   <target>, then the answer section of the response MUST include only
   the ANAME.  The response MUST also include the SOA, as it would in a
   NODATA response, along with NSEC or NSEC3 if applicable.  If another
   address type is present at the ANAME <target>, then it MAY be
   included in the additional section.

   If the original query is for type ANAME, both A and AAAA records MAY
   be returned in the additional section.

   If the original query is for type ANY, and if access to ANY query
   processing is not restricted, then the answer section MUST contain
   both the ANAME and the A and AAAA RRsets, if successfully resolved at
   the ANAME <target>.

   How and when an authoritative server resolves the address responses
   from the ANAME <target> (when it is not itself authoritative for
   <target>) is unspecified.  If the authoritative server is capable of
   performing recursive resolution, then it MAY resolve the query
   itself, or it MAY send address queries to an external resolver.  It
   MAY send address queries to the ANAME <target> when initially loading
   the zone, cache the responses locally, and refresh them periodically
   according to their TTLs, or it MAY delay resolution of address
   records until a query is received for the ANAME <owner>.  In either
   case, for performance reasons, it is RECOMMENDED that address records
   be cached locally by the authoritative server.

   Address records that are cached locally MUST have a limited TTL.  The
   initial TTL for locally-cached address records MUST not exceed the
   minimum of the ANAME TTL, the TTLs of the address records retrieved
   during ANAME <> resolution, and the TTLs of any intermediate ANAME,
   CNAME, or DNAME records.  The TTL of the cached address records MUST



Hunt, et al.             Expires August 13, 2018                [Page 5]

Internet-Draft                    aname                    February 2018


   count down, just as it would in a conventional resolver cache.
   Address records with expired TTLs MUST NOT be used to answer address
   queries until refreshed by sending a new query to the ANAME <target>,
   unless the server is configured to allow the use of stale data as
   described in [I-D.ietf-dnsop-serve-stale].

   If the original query is for a specific address type, resolution of
   address records at the ANAME <target> fails for any reason other than
   NXDOMAIN or NODATA, and cached data cannot be used, then the response
   MUST include the ANAME record and set the RCODE to SERVFAIL.

   If configured to do so, then the authoritative server MAY, when
   sending queries to the ANAME <target>, include an EDNS CLIENT-SUBNET
   (ECS) option [RFC7871], either forwarding an ECS option that was sent
   to it by the querying resolver, or by generating a new ECS option
   from the querying resolver's address.  If a response from the ANAME
   <target> includes an ECS option with a SCOPE PREFIX-LENGTH greater
   than zero, the response SHOULD be cached in such a way that it would
   subsequently only be used in response to queries from the same client
   subnet.

3.2.  Coexistence with other types

   If the zone is configured with an A or AAAA RRset at the same DNS
   node as ANAME, then the ANAME is considered to have already been
   expanded.  If during query processing any address records are found
   at the same node as an ANAME RR, then the ANAME RR MUST NOT be
   further expanded by the authoritative server.

   ANAME MUST NOT coexist with CNAME or any other RR type that restricts
   the types with which it can itself coexist.

   Like other types, ANAME MUST NOT exist below a DNAME, but it can
   coexist at the same node; in fact, the two can be used cooperatively
   to redirect both the owner name (via ANAME) and everything under it
   (via DNAME).

   ANAME can freely coexist at the same owner name with any other RR
   type.

3.3.  DNSSEC signing

   If the zone in which the ANAME resides is DNSSEC-signed, and if the
   server has access to its private zone-signing key, then the A and
   AAAA RRsets MUST be signed, either in advance when populating the A/
   AAAA answers for the ANAME records, or "on the fly" when responding
   to a query.




Hunt, et al.             Expires August 13, 2018                [Page 6]

Internet-Draft                    aname                    February 2018


   Because validating resolvers which do not yet implement ANAME will
   not be aware that this is an alias response, they will attempt to
   validate the A and AAAA responses included with an ANAME response as
   if they had originated from the ANAME <owner>.  Passing along the
   RRSIGs associated with the original A and AAAA RRsets from the ANAME
   <target> will not be sufficient for DNSSEC validation.  Consequently,
   if the server does not have access to the private zone-signing key,
   then it SHOULD NOT return unsigned address records unless every
   resolver with access to the zone is known to support ANAME.  (For
   instance, this might be the case in a split-horizon deployment where
   ANAME records are only served to an internal network with its own
   resolvers.)

   Implementers MAY allow address records associated with the ANAME to
   be populated and signed by the primary server, then sent along with
   their RRSIGs to secondaries via zone transfer.  In this case, the
   primary server MUST respect the TTLs of the address records, MUST
   refresh the address records by re-resolving the ANAME <target> when
   their TTLs expire, SHOULD respond to address queries with TTLs that
   count down as they would when answering from a normal DNS cache, and
   MUST inform secondary servers via DNS NOTIFY they need to refresh the
   zone when address records have been updated.  A secondary server
   SHOULD store address records and associated RRSIGs supplied via zone
   transfer in such a way that their TTLs will count down, as they would
   in a normal DNS cache, and ultimately trigger a zone refresh query
   upon reaching zero.  When a secondary server is responding to an
   address query, it SHOULD answer with the reduced TTL, but when
   responding to a zone transfer request, it MUST answer with the
   original TTL received from the primary.

   If this address record expansion and signing during zone transfer is
   not supported, then every authoritative server providing ANAME
   responses in a signed zone SHOULD have access to the private zone-
   signing key for that zone.  Deployment of ANAME in signed zones where
   address records cannot be signed due to lack of access to the private
   zone-signing key is NOT RECOMMENDED.

   When ANAME is present in a signed DNS node and address records exist
   at the ANAME <target>, the type bit map in the NSEC [RFC4034] or
   NSEC3 [RFC5155] record for that node MUST include bits for A and/or
   AAAA as well as ANAME.  This is for the benefit of validating
   resolvers not implementing ANAME which may use a signed proof of
   nonexistence for type A and AAAA to prevent address queries from
   being resolved.  The type bit map SHOULD only include address types
   which are known to exist at the <target>.






Hunt, et al.             Expires August 13, 2018                [Page 7]

Internet-Draft                    aname                    February 2018


4.  Recursive Server Behavior

   When a recursive resolver sends a query of type A or AAAA and
   receives a response with an ANAME RRset in the answer section, it
   MUST re-query for the ANAME <target>.  This is necessary because, in
   some cases, the address received will be dependent on network
   topology and other considerations, and the resolver may find a
   different answer than the authoritative server did.  (This
   requirement MAY be relaxed if both the ANAME <owner> and <target> are
   validly signed and provably in the same zone.)

   If resolution fails -- for example, due to the local resolver being
   nonfunctional or the ANAME <target> zone being unreachable -- then
   the resolver MAY use the address records that were included in the
   authoritative response as a fallback.  Otherwise, these records MUST
   NOT be cached or returned.

   If configured to do so, the resolver MAY include an EDNS CLIENT-
   SUBNET option [RFC7871] both when sending the initial query to the
   ANAME <owner> and when re-querying for the ANAME <target>.  If the
   response includes a SCOPE PREFIX-LENGTH greater than zero, the
   response SHOULD be cached in such a way that it would subsequently
   only be used in response to queries from the same client subnet.

5.  Examples

   Given the following zone:

   $ORIGIN example.com.
   @   IN SOA   example.com hostmaster.example.com 1 7200 600 1209600 60
   @   IN NS    ns1
   @   IN ANAME example.com.my-cdn.example.net.
   www IN CNAME example.com.my-cdn.example.net.

   A query for example.com/A would return the following:

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            5       IN      ANAME   example.com.my-cdn.example.net.
example.com.            5       IN      A       192.0.2.1

;; ADDITIONAL SECTION:
example.com.            5       IN      AAAA    2001:db8::1

   Similarly, for example.com/AAAA:




Hunt, et al.             Expires August 13, 2018                [Page 8]

Internet-Draft                    aname                    February 2018


;; QUESTION SECTION:
;example.com.                   IN      AAAA

;; ANSWER SECTION:
example.com.            5       IN      ANAME   example.com.my-cdn.example.net.
example.com.            5       IN      AAAA    2001:db8::1

;; ADDITIONAL SECTION:
example.com.            5       IN      A       192.0.2.1

   A query for example.com/ANAME would receive only the ANAME in the
   answer section, with the addresses for example.com.my-cdn.example.net
   expanded in the additional section:

;; QUESTION SECTION:
;example.com.                   IN      ANAME

;; ANSWER SECTION:
example.com.            5       IN      ANAME   example.com.my-cdn.example.net.

;; ADDITIONAL SECTION:
example.com.my-cdn.example.net. 5 IN    A       192.0.2.1
example.com.my-cdn.example.net. 5 IN    AAAA    2001:db8::1

   Meanwhile, a query for a non-address type would be returned normally:

   ;; QUESTION SECTION:
   ;example.com.                   IN      NS

   ;; ANSWER SECTION:
   example.com.            5       IN      NS      ns1.example.com.

6.  Operational Considerations

   When a zone containing ANAME records is transferred to a secondary
   server, the ANAME records are transferred, but the A or AAAA records
   retrieved from the ANAME <target> may not be.  If the primary server
   implements ANAME but the secondary server does not, then the two will
   return different answers for address queries.  It is therefore
   RECOMMENDED that ANAME not be deployed in a zone unless all of the
   authoritative servers for that zone implement ANAME, or the primary
   is able to expand the ANAME with the related address RRsets during
   the zone transfer.








Hunt, et al.             Expires August 13, 2018                [Page 9]

Internet-Draft                    aname                    February 2018


7.  Implementation Status

   PowerDNS <https://powerdns.com> currently implements a similar
   authoritative-only feature using "ALIAS" records, which are expanded
   by the primary server and transfered as address records to
   secondaries.

   [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS,
   Cloudflare, Amazon, and Akamai.]

8.  Security Considerations

   An authoritative server which implements ANAME resolves address
   queries on behalf of its clients, either internally or by querying an
   external resolver.  This resolution must be allowed to take place
   regardless of whether the client would ordinarily have been permitted
   by local policy to send recursive queries.

   When a resolver that does not understand ANAME receives a response
   containing A or AAAA records with <owner> rewritten to match that of
   the ANAME RR, this may bypass security mechanisms based on local
   policy limiting access to the original ANAME <target>.  One possible
   mitigation for this is to make sure the resolver being used during
   ANAME resolution lives outside of such critical network sections.

   If ANAME is used in a signed zone, validating resolvers that do not
   understand ANAME will not be able to validate the A and AAAA records
   included in the response, unless the responding server has added
   signatures for those records.  Merely passing along signatures from
   the <target> is not sufficient.  An authoritative server hosting a
   secure domain that includes ANAME SHOULD therefore have access to the
   private zone-signing key for that domain; otherwise, the operator
   must accept that validation failures will be common until ANAME is
   widly deployed.

   Both authoritative servers and resolvers that implement ANAME SHOULD
   carefully check for loops and treat them as an error condition.  One
   possible approach is to implement a hop counter and stop resolution
   when a maximum hop count is reached.

   An authoritative resolver returning address records which were
   obtained by resolving the ANAME <target> is supplying its own best
   information to clients as to the correct answer.  The response may be
   signed by the authoritative server, but that is not a guarantee of
   the actual correctness of the answer.  This can have the effect of
   promoting an insecure response from the ANAME <target> to a signed
   response from the <owner>, which may then appear to clients to be
   more trustworthy than it should.  To mitigate harm from this, DNSSEC



Hunt, et al.             Expires August 13, 2018               [Page 10]

Internet-Draft                    aname                    February 2018


   validation SHOULD be used when resolving the ANAME <target>.
   Authoritative servers MAY refuse to expand ANAME records unless the
   <target> node is both signed and validated.

9.  IANA Considerations

   IANA is requested to assign a DNS RR data type value for the ANAME RR
   type under the "Resource Record (RR) TYPEs" subregistry under the
   "Domain Name System (DNS) Parameters" registry.

   IANA may wish to consider the creation of a registry of address
   types; addition of new types to such a registry would then implicitly
   update this specification.

10.  Acknowledgments

   Thanks to Mukund Sivaraman, Stephen Morris, Ray Bellis, Mark Andrews,
   Richard Salts, Job Snijders, Richard Gibson, Hakan Lindqvist, Jan
   Vcelak, Tatuya JINMEI, Duane Wessels, Stefan Buehler, Bjorn Mott, and
   Tony Finch for discussion and feedback.

11.  References

11.1.  Normative References

   [I-D.ietf-dnsop-serve-stale]
              Lawrence, D. and W. Kumari, "Serving Stale Data to Improve
              DNS Resiliency", draft-ietf-dnsop-serve-stale-00 (work in
              progress), October 2017.

   [RFC1033]  Lottor, M., "Domain administrators operations guide",
              RFC 1033, November 1987.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

11.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.



Hunt, et al.             Expires August 13, 2018               [Page 11]

Internet-Draft                    aname                    February 2018


   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, June 2012.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016,
              <http://www.rfc-editor.org/info/rfc7871>.

Authors' Addresses

   Evan Hunt
   ISC
   950 Charter St
   Redwood City, CA  94063
   USA

   Email: each@isc.org


   Peter van Dijk
   PowerDNS.COM B.V.
   Den Haag
   The Netherlands

   Email: peter.van.dijk@powerdns.com


   Anthony Eden
   DNSimple
   Boston, MA
   USA

   Email: anthony.eden@dnsimple.com
   URI:   https://dnsimple.com/

















Hunt, et al.             Expires August 13, 2018               [Page 12]