< draft-ietf-dnsop-aname-03.txt   draft-ietf-dnsop-aname-04.txt >
DNS Operations T. Finch DNS Operations T. Finch
Internet-Draft University of Cambridge Internet-Draft University of Cambridge
Intended status: Standards Track E. Hunt Intended status: Standards Track E. Hunt
Expires: October 17, 2019 ISC Expires: January 9, 2020 ISC
P. van Dijk P. van Dijk
PowerDNS PowerDNS
A. Eden A. Eden
DNSimple DNSimple
W. Mekking W. Mekking
ISC ISC
April 15, 2019 July 8, 2019
Address-specific DNS aliases (ANAME) Address-specific DNS aliases (ANAME)
draft-ietf-dnsop-aname-03 draft-ietf-dnsop-aname-04
Abstract Abstract
This document defines the "ANAME" DNS RR type, to provide similar This document defines the "ANAME" DNS RR type, to provide similar
functionality to CNAME, but only for type A and AAAA queries. Unlike functionality to CNAME, but only for address queries. Unlike CNAME,
CNAME, an ANAME can coexist with other record types. The ANAME RR an ANAME can coexist with other record types. The ANAME RR allows
allows zone owners to make an apex domain name into an alias in a zone owners to make an apex domain name into an alias in a standards
standards compliant manner. compliant manner.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at line 65 skipping to change at line 65
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
1.2. Terminology 1.2. Terminology
2. The ANAME resource record 2. The ANAME resource record
2.1. Presentation and wire format 2.1. Presentation and wire format
2.2. Coexistence with other types 2.2. Coexistence with other types
3. Additional section processing 3. Substituting ANAME sibling address records
3.1. Address queries 4. ANAME processing by primary masters
3.2. ANAME queries 4.1. Zone transfers
4. Substituting ANAME sibling address records 4.2. DNSSEC
5. ANAME processing by primary masters 4.3. TTLs
5.1. Zone transfers 5. ANAME processing by resolvers
5.2. DNSSEC 6. Query processing
5.3. TTLs 6.1. Authoritative servers
6. ANAME processing by resolvers 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 7. IANA considerations
8. Security considerations 8. Security considerations
9. Acknowledgments 9. Acknowledgments
10. Changes since the last revision 10. Changes since the last revision
10.1. Version -03 10.1. Version -04
10.2. Version -02 10.2. Version -03
10.3. Version -02
11. References 11. References
11.1. Normative References 11.1. Normative References
11.2. Informative References 11.2. Informative References
11.3. URIs 11.3. URIs
Appendix A. Implementation status Appendix A. Implementation status
Appendix B. Historical note Appendix B. Historical note
Appendix C. On preserving TTLs Appendix C. On preserving TTLs
C.1. Query bunching C.1. Query bunching
C.2. Upstream caches C.2. Upstream caches
C.3. ANAME chains C.3. ANAME chains
C.4. TTLs and zone transfers C.4. ANAME substitution inside the name server
Appendix D. Answer vs Additional sections C.5. TTLs and zone transfers
Appendix E. Alternative setups Appendix D. Alternative setups
D.1. Reducing query volume
D.2. Zone transfer scalability
D.3. Tailored responses
Appendix E. ANAME loops
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
It can be desirable to provide web sites (and other services) at a 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- bare domain name (such as "example.com") as well as a service-
specific subdomain ("www.example.com"). specific subdomain ("www.example.com").
If the web site is hosted by a third-party provider, the ideal way to 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 provision its name in the DNS is using a CNAME record, so that the
skipping to change at line 121 skipping to change at line 130
be present there. CNAME records can also conflict at subdomains, for be present there. CNAME records can also conflict at subdomains, for
example, if "department.example.edu" has separately hosted mail and example, if "department.example.edu" has separately hosted mail and
web servers. web servers.
Redirecting website lookups to an alternate domain name via SRV or Redirecting website lookups to an alternate domain name via SRV or
URI resource records would be an effective solution from the DNS URI resource records would be an effective solution from the DNS
point of view, but to date, browser vendors have not accepted this point of view, but to date, browser vendors have not accepted this
approach. approach.
As a result, the only widely supported and standards-compliant way to As a result, the only widely supported and standards-compliant way to
publish a web site at a bare domain is to place A and/or AAAA records publish a web site at a bare domain is to place address records (A
at the zone apex. The flexibility afforded by CNAME is not and/or AAAA) at the zone apex. The flexibility afforded by CNAME is
available. not available.
This document specifies a new RR type "ANAME", which provides similar This document specifies a new RR type "ANAME", which provides similar
functionality to CNAME, but only for address queries (i.e., for type functionality to CNAME, but only for address queries (i.e., for type
A or AAAA). The basic idea is that the address records next to an A or AAAA). The basic idea is that the address records next to an
ANAME record are automatically copied from and kept in sync with the ANAME record are automatically copied from and kept in sync with the
ANAME target's address records. The ANAME record can be present at ANAME target's address records. The ANAME record can be present at
any DNS node, and can coexist with most other RR types, enabling it any DNS node, and can coexist with most other RR types, enabling it
to be present at a zone apex, or any other name where the presence of to be present at a zone apex, or any other name where the presence of
other records prevents the use of a CNAME record. other records prevents the use of a CNAME record.
skipping to change at line 154 skipping to change at line 163
The core functionality of this mechanism allows zone administrators The core functionality of this mechanism allows zone administrators
to start using ANAME records unilaterally, without requiring to start using ANAME records unilaterally, without requiring
secondary servers or resolvers to be upgraded. secondary servers or resolvers to be upgraded.
o The resource record definition in Section 2 is intended to provide o The resource record definition in Section 2 is intended to provide
zone data portability between standards-compliant DNS servers and zone data portability between standards-compliant DNS servers and
the common core functionality of existing proprietary ANAME-like the common core functionality of existing proprietary ANAME-like
facilities. facilities.
o The zone maintenance mechanism described in Section 5 keeps the o The zone maintenance mechanism described in Section 4 keeps the
ANAME's sibling address records in sync with the ANAME target. ANAME's sibling address records in sync with the ANAME target.
This definition is enough to be useful by itself. However, it can be This definition is enough to be useful by itself. However, it can be
less than optimal in certain situations: for instance, when the ANAME less than optimal in certain situations: for instance, when the ANAME
target uses clever tricks to provide different answers to different target uses clever tricks to provide different answers to different
clients to improve latency or load balancing. clients to improve latency or load balancing. The query processing
rules in Section 6 require to include the ANAME record so that
o The Additional section processing rules in Section 3 inform resolvers can use this information (as described in Section 5) to
resolvers that an ANAME record is in play. obtain answers that are tailored to the resolver rather than to the
zone's primary master.
o Resolvers can use this ANAME information as described in Section 6
to obtain answers that are tailored to the resolver rather than to
the zone's primary master.
Resolver support for ANAME is not necessary, since ANAME-oblivious Resolver support for ANAME is not necessary, since ANAME-oblivious
resolvers can get working answers from authoritative servers. It's resolvers can get working answers from authoritative servers. It's
just an optimization that can be rolled out incrementally, and that just an optimization that can be rolled out incrementally, and that
will help ANAME to work better the more widely it is deployed. will help ANAME to work better the more widely it is deployed.
1.2. Terminology 1.2. Terminology
An "address record" is a DNS resource record whose type is A or AAAA. An "address record" is a DNS resource record whose type is A or AAAA.
These are referred to as "address types". "Address query" refers to These are referred to as "address types". "Address query" refers to
skipping to change at line 192 skipping to change at line 198
NXDOMAIN or NODATA) the same successfully resolving as a set of zero NXDOMAIN or NODATA) the same successfully resolving as a set of zero
address records, and distinct from "failure" which covers error address records, and distinct from "failure" which covers error
responses such as SERVFAIL or REFUSED. responses such as SERVFAIL or REFUSED.
The "sibling address records" of an ANAME record are the address The "sibling address records" of an ANAME record are the address
records at the same owner name as the ANAME, which are subject to records at the same owner name as the ANAME, which are subject to
ANAME substitution. ANAME substitution.
The "target address records" of an ANAME record are the address The "target address records" of an ANAME record are the address
records obtained by resolving the ultimate target of the ANAME (see records obtained by resolving the ultimate target of the ANAME (see
Section 4). Section 3).
During the process of looking up the target address records, one or
more CNAME or ANAME records may be encountered. These records are
not the final target address records, and are referred in this
document as "intermediate records". The target name must be replaced
with the new name provided in the RDATA and the new target is
resolved.
Other DNS-related terminology can be found in [RFC8499]. Other DNS-related terminology can be found in [RFC8499].
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
2. The ANAME resource record 2. The ANAME resource record
This document defines the "ANAME" DNS resource record type, with RR This document defines the "ANAME" DNS resource record type, with RR
skipping to change at line 221 skipping to change at line 234
The wire format is also identical to CNAME [RFC1035], except that The wire format is also identical to CNAME [RFC1035], except that
name compression is not permitted in ANAME RDATA, per [RFC3597]. name compression is not permitted in ANAME RDATA, per [RFC3597].
2.2. Coexistence with other types 2.2. Coexistence with other types
Only one ANAME <target> can be defined per <owner>. An ANAME RRset Only one ANAME <target> can be defined per <owner>. An ANAME RRset
MUST NOT contain more than one resource record. MUST NOT contain more than one resource record.
An ANAME's sibling address records are under the control of ANAME An ANAME's sibling address records are under the control of ANAME
processing (see Section 5) and are not first-class records in their processing (see Section 4) and are not first-class records in their
own right. They MAY exist in zone files, but they can subsequently own right. They MAY exist in zone files, but they can subsequently
be altered by ANAME processing. be altered by ANAME processing.
ANAME records MAY freely coexist at the same owner name with other RR An ANAME record MAY freely coexist at the same owner name with other
types, except they MUST NOT coexist with CNAME or any other RR type RR types, except they MUST NOT coexist with CNAME or any other RR
that restricts the types with which it can itself coexist. type that restricts the types with which it can itself coexist. That
means An ANAME record can coexist at the same owner name with A and
AAAA records. These are the sibling address records that are updated
with the target addresses that are retrieved through the ANAME
substitution process Section 3.
Like other types, ANAME records can coexist with DNAME records at the Like other types, An ANAME record can coexist with DNAME records at
same owner name; in fact, the two can be used cooperatively to the same owner name; in fact, the two can be used cooperatively to
redirect both the owner name address records (via ANAME) and redirect both the owner name address records (via ANAME) and
everything under it (via DNAME). everything under it (via DNAME).
3. Additional section processing 3. Substituting ANAME sibling address records
The requirements in this section apply to both recursive and
authoritative servers.
An ANAME target MAY resolve to address records via a chain of CNAME
and/or ANAME records; any CNAME/ANAME chain MUST be included when
adding target address records to a response's Additional section.
3.1. Address queries
When a server receives an address query for a name that has an ANAME
record, the response's Additional section:
o MUST contain the ANAME record;
o MAY contain the target address records that match the query type
(or the corresponding proof of nonexistence), if they are
available and the target address RDATA fields differ from the
sibling address RRset.
The ANAME record indicates to a client that it might wish to resolve
the target address records itself. The target address records might
not be available if the server is authoritative and does not include
out-of-zone or non-authoritative data in its answers, or if the
server is recursive and the records are not in the cache.
3.2. ANAME queries
When a server receives an query for type ANAME, there are three
possibilities:
o The query resolved to an ANAME record, and the server has the
target address records; any target address records SHOULD be added
to the Additional section.
o The query resolved to an ANAME record, and the server does not
have the target address records; any sibling address records
SHOULD be added to the Additional section.
o The query did not resolve to an ANAME record; any address records
with the same owner name SHOULD be added to the Additional section
of the NOERROR response.
When adding address records to the Additional section, if not all
address types are present and the zone is signed, the server SHOULD
include a DNSSEC proof of nonexistence for the missing address types.
4. Substituting ANAME sibling address records
This process is used by both primary masters (see Section 5) and This process is used by both primary masters (see Section 4) and
resolvers (see Section 6), though they vary in how they apply the resolvers (see Section 5), though they vary in how they apply the
edit described in the final step. edit described in the final step. However, this process is not
exclusively used by primary masters and resolvers: it may be executed
as a bump in the wire, as part of the query lookup, or at any other
point during query resolution.
The following steps MUST be performed for each address type: The following steps MUST be performed for each address type:
1. Starting at the ANAME owner, follow the chain of ANAME and/or 1. Starting at the ANAME owner, follow the chain of ANAME and/or
CNAME records as far as possible to find the ultimate target. CNAME records as far as possible to find the ultimate target.
2. If a loop is detected, continue with an empty RRset, otherwise 2. If a loop is detected, continue with an empty RRset, otherwise
get the ultimate target's address records. (Ignore any sibling get the ultimate target's address records. (Ignore any sibling
address records of intermediate ANAMEs.) address records of intermediate ANAMEs.)
3. Stop if resolution failed. (Note that NXDOMAIN and NODATA count 3. Stop if resolution failed. (Note that NXDOMAIN and NODATA count
as successfully resolving an empty RRset.) as successfully resolving an empty RRset.)
4. Replace the owner of the target address records with the owner of 4. If one or more address records are found, replace the owner of
the ANAME record. Reduce the TTL to match the ANAME record if it the target address records with the owner of the ANAME record.
is greater. Drop any RRSIG records. Set the TTL to the minimum of the ANAME TTL, the TTL of each
intermediate record, and the TTL of the target address records.
Drop any RRSIG records.
5. Stop if this modified RRset is the same as the sibling RRset 5. Stop if this modified RRset is the same as the sibling RRset
(ignoring any RRSIG records). The comparison MAY treat nearly- (ignoring any RRSIG records). The comparison MAY treat nearly-
equal TTLs as the same. equal TTLs as the same.
6. Delete the sibling address RRset and replace it with the modified 6. Delete the sibling address RRset (if any) and replace it with the
RRset. modified RRset.
At this point, the substituted RRset is not signed. A primary master At this point, the substituted RRset is not signed. A primary master
will proceed to sign the substituted RRset, whereas resolvers can will proceed to sign the substituted RRset, whereas resolvers can
only use the substituted RRset when an unsigned answer is only use the substituted RRset when an unsigned answer is
appropriate. This is explained in more detail in the following appropriate. This is explained in more detail in the following
sections. sections.
5. ANAME processing by primary masters 4. ANAME processing by primary masters
Each ANAME's sibling address records are kept up-to-date as if by the Each ANAME's sibling address records are kept up-to-date as if by the
following process, for each address type: following process, for each address type:
o Perform ANAME sibling address record substitution as described in o Perform ANAME sibling address record substitution as described in
Section 4. Any edit performed in the final step is applied to the Section 3. Any edit performed in the final step is applied to the
ANAME's zone. A primary server MAY use Dynamic Updates (DNS ANAME's zone. A primary server MAY use Dynamic Updates (DNS
UPDATE) [RFC2136] to update the zone. UPDATE) [RFC2136] to update the zone.
o If resolution failed, wait for a period before trying again. This o If resolution failed, wait for a period before trying again. This
retry time SHOULD be configurable. retry time SHOULD be configurable.
o Otherwise, wait until the target address record TTL has expired, o Otherwise, wait until the target address RRset TTL has expired or
then repeat. is close to expiring, then repeat.
It may be more efficient to manage the polling per ANAME target It may be more efficient to manage the polling per ANAME target
rather than per ANAME as specified (for example if the same ANAME rather than per ANAME as specified (for example if the same ANAME
target is used by multiple zones). target is used by multiple zones).
Sibling address records are committed to the zone and stored in Sibling address records are committed to the zone and stored in
nonvolatile storage. This allows a server to restart without delays nonvolatile storage. This allows a server to restart without delays
due to ANAME processing, use offline DNSSEC signing, and not due to ANAME processing, use offline DNSSEC signing, and not
implement special ANAME processing logic when handling a DNS query. implement special ANAME processing logic when handling a DNS query.
Appendix E describes how ANAME would fit in different DNS Appendix D describes how ANAME would fit in different DNS
architectures that use online signing or tailored responses. architectures that use online signing or tailored responses.
5.1. Zone transfers 4.1. Zone transfers
ANAME is no more special than any other RRtype and does not introduce ANAME is no more special than any other RRtype and does not introduce
any special processing related to zone transfers. any special processing related to zone transfers.
A zone containing ANAME records that point to frequently-changing A zone containing ANAME records that point to frequently-changing
targets will itself change frequently, and may see an increased targets will itself change frequently, and may see an increased
number of zone transfers. Or if a very large number of zones are number of zone transfers. Or if a very large number of zones are
sharing the same ANAME target, and that changes address, that may sharing the same ANAME target, and that changes address, that may
cause a great volume of zone transfers. Guidance on dealing with cause a great volume of zone transfers. Guidance on dealing with
ANAME in large scale implementations is provided Appendix E. ANAME in large scale implementations is provided Appendix D.
Secondary servers that rely on zone transfers to obtain sibling Secondary servers rely on zone transfers to obtain sibling address
address records, just like the rest of the zone, and serve them in records, just like the rest of the zone, and serve them in the usual
the usual way (with Section 3 Additional section processing if they way (see Section 6). A working DNS NOTIFY [RFC1996] setup is
support it). A working DNS NOTIFY [RFC1996] setup is recommended to recommended to avoid extra delays propagating updated sibling address
avoid extra delays propagating updated sibling address records when records when they change.
they change.
5.2. DNSSEC 4.2. DNSSEC
A zone containing ANAME records that will update A and AAAA records A zone containing ANAME records that will update address records has
has to do so before signing the zone with DNSSEC [RFC4033] [RFC4034] to do so before signing the zone with DNSSEC [RFC4033] [RFC4034]
[RFC4035]. [RFC4035]. This means that for traditional DNSSEC signing the
substitution of sibling address records must be done before signing
and loading the zone into the name server. For servers that support
online signing, the substitution may happen as part of the name
server process, after loading the zone.
DNSSEC signatures on sibling address records are generated in the DNSSEC signatures on sibling address records are generated in the
same way as for normal (dynamic) updates. same way as for normal (dynamic) updates.
5.3. TTLs 4.3. TTLs
Sibling address records are served from authoritative servers with a Sibling address records are served from authoritative servers with a
fixed TTL. Normally this TTL is expected to be the same as the fixed TTL. Normally this TTL is expected to be the same as the
target address records' TTL (or the ANAME TTL if that is smaller); target address records' TTL; however the exact mechanism for
however the exact mechanism for obtaining the target is unspecified, obtaining the target is unspecified, so cache effects, following
so cache effects or deliberate policies might make the sibling TTL ANAME and CNAME chains, or deliberate policies might make the sibling
smaller. There is a more extended discussion of TTL handling in TTL smaller.
{#ttls}.
6. ANAME processing by resolvers This means that when adding address records into the zone as a result
of ANAME processing, the TTL to use is at most that of the TTL of the
address target records. If you use a higher value, this will stretch
the TTL which is undesired.
TTL stretching is hard to avoid when implementing ANAME substitution
at the primary: The target address records' TTL influences the update
rate of the zone, while the sibling address records' TTL determine
how long a resolver may cache the address records. Thus, the end-to-
end TTL (from the authoritative servers for the target address
records to end-user DNS caches) is nearing twice the target address
record TTL. There is a more extended discussion of TTL handling in
Appendix C.
5. ANAME processing by resolvers
When a resolver makes an address query in the usual way, it might When a resolver makes an address query in the usual way, it might
receive a response containing ANAME information in the additional receive a response containing ANAME information in the Answer
section, as described in Section 3. This informs the resolver that section, as described in Section 6. This informs the resolver that
it MAY resolve the ANAME target address records to get answers that it MAY resolve the ANAME target address records to get answers that
are tailored to the resolver rather than the ANAME's primary master. are tailored to the resolver rather than the ANAME's primary master.
It SHOULD include the target address records in the Additional
section of its responses as described in Section 3.
In order to provide tailored answers to clients that are ANAME- In order to provide tailored answers to clients that are ANAME-
oblivious, the resolver MAY perform sibling address record oblivious, the resolver MAY perform sibling address record
substitution in the following situations: substitution in the following situations:
o The resolver's client queries with DO=0. (As discussed in o The resolver's client queries with DO=0. (As discussed in
Section 8, if the resolver finds it would downgrade a secure Section 8, if the resolver finds it would downgrade a secure
answer to insecure, it MAY choose not to substitute the sibling answer to insecure, it MAY choose not to substitute the sibling
address records.) address records.)
o The resolver's client queries with DO=1 and the ANAME and sibling o The resolver's client queries with DO=1 and the ANAME and sibling
address records are unsigned. (Note that this situation does not address records are unsigned. (Note that this situation does not
apply when the records are signed but insecure: the resolver might apply when the records are signed but insecure: the resolver might
not be able to validate them because of a broken chain of trust, not be able to validate them because of a broken chain of trust,
but its client could have an extra trust anchor that does allow it but its client could have an extra trust anchor that does allow it
to validate them; if the resolver substitutes the sibling address to validate them; if the resolver substitutes the sibling address
records they will become bogus.) records they will become bogus.)
In these first two cases, the resolver MAY perform ANAME sibling In these first two cases, the resolver MAY perform ANAME sibling
address record substitution as described in Section 4. Any edit address record substitution as described in Section 3. Any edit
performed in the final step is applied to the Answer section of the performed in the final step is applied to the Answer section of the
response. The resolver SHOULD then perform Additional section response.
processing as described in Section 3.
If the resolver's client is querying using an API such as If the resolver's client is querying using an API such as
"getaddrinfo" [RFC3493] that does not support DNSSEC validation, the "getaddrinfo" [RFC3493] that does not support DNSSEC validation, the
resolver MAY perform ANAME sibling address record substitution as resolver MAY perform ANAME sibling address record substitution as
described in Section 4. Any edits performed in the final step are described in Section 3. Any edits performed in the final step are
applied to the addresses returned by the API. (This case is for applied to the addresses returned by the API. (This case is for
validating stub resolvers that query an upstream recursive server validating stub resolvers that query an upstream recursive server
with DO=1, so they cannot rely on the recursive server to do ANAME with DO=1, so they cannot rely on the recursive server to do ANAME
substitution for them.) substitution for them.)
6. Query processing
6.1. Authoritative servers
6.1.1. Address queries
When a server receives an address query for a name that has an ANAME
record, the response's Answer section MUST contain the ANAME record,
in addition to the sibling address queries. The ANAME record
indicates to a client that it might wish to resolve the target
address records itself.
6.1.2. ANAME queries
When a server receives an query for type ANAME, regardless of whether
the ANAME record exists on the queried domain, any sibling address
records SHOULD be added to the Additional section. Note that the
sibling address records may have been substituted already.
When adding address records to the Additional section, if not all
address types are present and the zone is signed, the server SHOULD
include a DNSSEC proof of nonexistence for the missing address types.
6.2. Resolvers
6.2.1. Address queries
When a server receives an address query for a name that has an ANAME
record, the response's Answer section MUST contain the ANAME record,
in addition to the sibling address queries.
The Additional section MAY contain the target address records that
match the query type (or the corresponding proof of nonexistence), if
they are available in the cache and the target address RDATA fields
differ from the sibling address RRset.
An ANAME target MAY resolve to address records via a chain of CNAME
and/or ANAME records; any CNAME/ANAME chain MUST be included when
adding target address records to a response's Additional section.
6.2.2. ANAME queries
When a resolver receives an query for type ANAME, any sibling address
records SHOULD be added to the Additional section. Just like with an
authoritative server, when adding address records to the Additional
section, if not all address types are present and the zone is signed,
the resolver SHOULD include a DNSSEC proof of nonexistence for the
missing address types.
7. IANA considerations 7. IANA considerations
IANA is requested to assign a DNS RR TYPE value for ANAME resource IANA is requested to assign a DNS RR TYPE value for ANAME resource
records under the "Resource Record (RR) TYPEs" subregistry under the records under the "Resource Record (RR) TYPEs" subregistry under the
"Domain Name System (DNS) Parameters" registry. "Domain Name System (DNS) Parameters" registry.
IANA might wish to consider the creation of a registry of address IANA might wish to consider the creation of a registry of address
types; addition of new types to such a registry would then implicitly types; addition of new types to such a registry would then implicitly
update this specification. update this specification.
skipping to change at line 468 skipping to change at line 504
resolver's path to the ANAME target's servers. Resolvers MAY choose resolver's path to the ANAME target's servers. Resolvers MAY choose
not to substitute sibling address records when they are more secure not to substitute sibling address records when they are more secure
than the target address records. than the target address records.
9. Acknowledgments 9. Acknowledgments
Thanks to Mark Andrews, Ray Bellis, Stefan Buehler, Paul Ebersman, Thanks to Mark Andrews, Ray Bellis, Stefan Buehler, Paul Ebersman,
Richard Gibson, Tatuya JINMEI, Hakan Lindqvist, Mattijs Mekking, Richard Gibson, Tatuya JINMEI, Hakan Lindqvist, Mattijs Mekking,
Stephen Morris, Bjorn Mott, Richard Salts, Mukund Sivaraman, Job Stephen Morris, Bjorn Mott, Richard Salts, Mukund Sivaraman, Job
Snijders, Jan Vcelak, Paul Vixie, Duane Wessels, and Paul Wouters, Snijders, Jan Vcelak, Paul Vixie, Duane Wessels, and Paul Wouters,
Olli Vanhoja for discussion and feedback. Olli Vanhoja, Brian Dickson for discussion and feedback.
10. Changes since the last revision 10. Changes since the last revision
[This section is to be removed before publication as an RFC.] [This section is to be removed before publication as an RFC.]
The full history of this draft and its issue tracker can be found at The full history of this draft and its issue tracker can be found at
https://github.com/each/draft-aname [1] https://github.com/each/draft-aname [1]
10.1. Version -03 10.1. Version -04
o Split up section about Additional Section processing.
o Update Additional Section processing requirements.
o Clarify when ANAME resolution may happen [#43].
o Revisit TTL considerations [#30, #34].
o ANAME goes into the Answer section when QTYPE=A|AAAA [#62].
o Update alternative setups section with concerns (Brian Dickson)
[#68].
o Add section on ANAME loops (open issue [#45]).
10.2. Version -03
o Grammar improvements (Olli Vanhoja) o Grammar improvements (Olli Vanhoja)
o Split up Implications section, clarify text on zone transfers and o Split up Implications section, clarify text on zone transfers and
dynamic updates. dynamic updates [#39].
o Rewrite Alternative setup section and move to Appendix, add text o Rewrite Alternative setup section and move to Appendix, add text
on zone transfer scalibility concerns and GeoIP. on zone transfer scalibility concerns and GeoIP.
10.2. Version -02 10.3. Version -02
Major revamp, so authoritative servers (other than primary masters) Major revamp, so authoritative servers (other than primary masters)
now do not do any special ANAME processing, just Additional section now do not do any special ANAME processing, just Additional section
processing. processing.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", [RFC1033] Lottor, M., "Domain Administrators Operations Guide",
skipping to change at line 534 skipping to change at line 587
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[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,
<https://www.rfc-editor.org/info/rfc7871>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
11.2. Informative References 11.2. Informative References
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983, RFC 882, DOI 10.17487/RFC0882, November 1983,
<https://www.rfc-editor.org/info/rfc882>. <https://www.rfc-editor.org/info/rfc882>.
skipping to change at line 573 skipping to change at line 631
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003, RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>. <https://www.rfc-editor.org/info/rfc3493>.
11.3. URIs 11.3. URIs
[1] https://github.com/each/draft-aname [1] https://github.com/each/draft-aname
[2] https://github.com/each/draft-aname/issues/45
Appendix A. Implementation status Appendix A. Implementation status
PowerDNS currently implements a similar authoritative-only feature PowerDNS currently implements a similar authoritative-only feature
using "ALIAS" records, which are expanded by the primary server and using "ALIAS" records, which are expanded by the primary server and
transfered as address records to secondaries. transfered as address records to secondaries.
[TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS,
Cloudflare, Amazon, Dyn, and Akamai.] Cloudflare, Amazon, Dyn, and Akamai.]
Appendix B. Historical note Appendix B. Historical note
skipping to change at line 641 skipping to change at line 701
are authoritative data in the owner's zone, so from that point of are authoritative data in the owner's zone, so from that point of
view the owner has the last say over what their TTL should be; on the view the owner has the last say over what their TTL should be; on the
other hand, ANAMEs are supposed to act as aliases, in which case the other hand, ANAMEs are supposed to act as aliases, in which case the
target should control the address record TTLs. target should control the address record TTLs.
However there are some technical constraints that make it difficult However there are some technical constraints that make it difficult
to preserve the target address record TTLs. to preserve the target address record TTLs.
The following subsections conclude that the end-to-end TTL (from the The following subsections conclude that the end-to-end TTL (from the
authoritative servers for the target address records to end-user DNS authoritative servers for the target address records to end-user DNS
caches) should be set as the target address record TTL plus the caches) is nearing twice the target address record TTL.
sibling address record TTL.
[MM: Discuss: I think it should be just the ANAME record TTL perhaps
the minimum of ANAME and sibling address RRset TTL. We should
provide some guidance on TTL settings for ANAME).
[TF: see issue #30]
C.1. Query bunching C.1. Query bunching
If the times of end-user queries for a domain name are well If the times of end-user queries for a domain name are well
distributed, then (typically) queries received by the authoritative distributed, then (typically) queries received by the authoritative
servers for that domain are also well distributed. If the domain is servers for that domain are also well distributed. If the domain is
popular, a recursive server will re-query for it once every TTL popular, a recursive server will re-query for it once every TTL
seconds, but the periodic queries from all the various recursive seconds, but the periodic queries from all the various recursive
servers will not be aligned, so the queries remain well distributed. servers will not be aligned, so the queries remain well distributed.
skipping to change at line 689 skipping to change at line 742
However, not all zones are signed, and a primary master might not be However, not all zones are signed, and a primary master might not be
able to query other authoritative servers directly (e.g. if it is a able to query other authoritative servers directly (e.g. if it is a
hidden primary behind a strict firewall). Instead it might have to hidden primary behind a strict firewall). Instead it might have to
obtain an ANAME's target address records via some other recursive obtain an ANAME's target address records via some other recursive
server. server.
Querying via a separate recursive server means the primary master Querying via a separate recursive server means the primary master
cannot trivially obtain the target address records' original TTLs. cannot trivially obtain the target address records' original TTLs.
Fortunately this is likely to be a self-correcting problem for Fortunately this is likely to be a self-correcting problem for
similar reasons to the query-bunching discussed in the previous similar reasons to the query-bunching discussed in the previous
subsection. The primary master re-checks the target address records subsection. The primary master can inspect the target address
just after the TTL expires when its upstream cache has just refreshed records just after the TTL expires when its upstream cache has just
them, so the TTL will be nearly equal to the original TTL. refreshed them, so the TTL will be nearly equal to the original TTL.
A related consideration is that the primary master cannot in general A related consideration is that the primary master cannot in general
refresh its copies of an ANAME's target address records more refresh its copies of an ANAME's target address records more
frequently than their TTL, without privileged control over its frequently than their TTL, without privileged control over its
resolver cache. resolver cache.
Combined with the requirement that sibling address records are served Combined with the requirement that sibling address records are served
with a fixed TTL, this means that the end-to-end TTL will be the with a fixed TTL, this means that the end-to-end TTL will be the
target address record TTL (which determines when the sibling address target address record TTL (which determines when the sibling address
records are updated) plus the sibling address record TTL (which records are updated) plus the sibling address record TTL (which
determines when end-user caches are updated). determines when end-user caches are updated). Since the sibling
address record TTL is derived from the target address records'
original TTL, the end-to-end TTL will be nearing twice the target
address record TTL.
C.3. ANAME chains C.3. ANAME chains
ANAME sibling address record substitution is made slightly more ANAME sibling address record substitution is made slightly more
complicated by the requirement to follow chains of ANAME and/or CNAME complicated by the requirement to follow chains of ANAME and/or CNAME
records. The TTL of the substituted address records is the minimum
of TTLs of the ANAME, all the intermediate records, and target
records. This stops the end-to-end TTL from being inflated by each records. This stops the end-to-end TTL from being inflated by each
ANAME in the chain. ANAME in the chain.
C.4. TTLs and zone transfers With CNAME records, repeat queries for "cname.example. CNAME
target.example." must not be fully answered from cache after its TTL
expires, but must instead be sent to name servers authoritative for
"cname.example" in case the CNAME has been updated or removed.
Similarly, an ANAME at "aname.example" means that repeat queries for
"aname.example" must not be fully answered from cache after its TTL
expire, but must instead be sent to name servers authoritative for
aname.example in case the ANAME has been updated or removed.
C.4. ANAME substitution inside the name server
When ANAME substitution is performed inside the authoritative name
server (as described in #alternatives) or in the resolver (as
described in #resolver) the end-to-end TTL will actually be just the
target address record TTL.
An authoritative server that has control over its resolver can use a
cached target address RRset and decremented TTL in the response to
the client rather than using the original target address records'
TTL. It SHOULD however not use TTLs in the response that are nearing
zero to avoid query bunching Appendix C.1.
A resolver that performs ANAME substitution is able to get the
original TTL from the authoritative name server and use its own cache
to store the substituted address records with the appropriate TTL,
thereby honoring the TTL of target address records.
C.5. TTLs and zone transfers
When things are working properly (with secondary name servers When things are working properly (with secondary name servers
responding to NOTIFY messages promptly) the authoritative servers responding to NOTIFY messages promptly) the authoritative servers
will follow changes to ANAME target address records according to will follow changes to ANAME target address records according to
their TTLs. As a result the end-to-end TTL is unchanged from the their TTLs. As a result the end-to-end TTL is unchanged from the
previous subsection. previous subsection.
If NOTIFY doesn't work, the TTLs can be stretched by the zone's SOA If NOTIFY doesn't work, the TTLs can be stretched by the zone's SOA
refresh timer. More serious breakage can stretch them up to the zone refresh timer. More serious breakage can stretch them up to the zone
expiry time. expiry time.
Appendix D. Answer vs Additional sections Appendix D. Alternative setups
[MM: Discuss what should be in the additional section: ANAME makes If you are a large scale DNS provider, ANAME may introduce some
sense, but differs from CNAME logic (where the CNAME is in the answer operational concerns.
section). Additional target records that match the query type in my
opinion should go in the answer section. Additional target address
records that do not match the query type can go in the additional
section].
[TF: from experience with DNAME I think there's a risk of interop D.1. Reducing query volume
problems if we put unexpected records in the answer section, so I
said everything should go in additional. We'll expand this appendix
to explain the rationale.]
Appendix E. Alternative setups When doing ANAME target lookups, an authoritative server might want
to use longer TTLs to reduce query volume, for ANAME values that do
not change frequently. This is the same concern a recursive resolver
may be exposed to when receiving answers with short TTLs. An
authoritative server doing ANAME target lookups therefor could use
the same mitigation as a recursive nameserver, that is set a
configured minimum TTL usage. This may however contribute to TTL
stretching as described in Section 4.3 so the configured minimum
should not be too low.
If you are a large scale DNS provider, ANAME may introduce some D.2. Zone transfer scalability
scalability concerns. A frequently changing ANAME target, or a ANAME
target that changes its address and is used for many zones, can lead A frequently changing ANAME target, or a ANAME target that changes
to an increased number of zone transfers. Such DNS architectures may its address and is used for many zones, can lead to an increased
want to consider a zone transfer mechanism outside the DNS. number of zone transfers. Such DNS architectures may want to
consider a zone transfer mechanism outside the DNS.
Another way to deal with zone transfer scalability is to move the Another way to deal with zone transfer scalability is to move the
ANAME processing (Section 4) inside the name server daemon. This is ANAME processing (Section 3) inside the name server daemon. This is
not a requirement for ANAME to work, but may be a better solution in not a requirement for ANAME to work, but may be a better solution in
large scale implementations. These implementations usually already large scale implementations. These implementations usually already
rely on online DNSSEC signing for similar reasons. If ANAME rely on online DNSSEC signing for similar reasons. If ANAME
processing occurs inside the name server daemon, it MUST be done processing occurs inside the name server daemon, it MUST be done
before any DNSSEC online signing happens. before any DNSSEC online signing happens.
For example, some existing ANAME-like implementations are based on a For example, some existing ANAME-like implementations are based on a
DNS server architecture, in which a zone's published authoritative DNS server architecture, in which a zone's published authoritative
servers all perform the duties of a primary master in a distributed servers all perform the duties of a primary master in a distributed
manner: provisioning records from a non-DNS back-end store, manner: provisioning records from a non-DNS back-end store,
refreshing DNSSEC signatures, and so forth. They don't use standard refreshing DNSSEC signatures, and so forth. They don't use standard
standard zone transfers, and already implement their ANAME-like standard zone transfers, and already implement their ANAME-like
processing inside the name server daemon, substituting ANAME sibling processing inside the name server daemon, substituting ANAME sibling
address records on demand. address records on demand.
Also, some DNS providers will tailor responses based on information D.3. Tailored responses
in the client request. Such implementations will use the source IP
address or EDNS Client Subnet information and use geographical data Some DNS providers will tailor responses based on information in the
client request. Such implementations will use the source IP address
or EDNS Client Subnet [RFC7871] information and use geographical data
(GeoIP) or network latency measurements to decide what the best (GeoIP) or network latency measurements to decide what the best
answer is for a given query. Such setups won't work with traditional answer is for a given query. Such setups won't work with traditional
DNSSEC and provide DNSSEC support usually through online signing. DNSSEC and provide DNSSEC support usually through online signing.
Similar such setups should provide ANAME support through substituting Similar such setups should provide ANAME support through substituting
ANAME sibling records on demand. ANAME sibling records on demand.
The exact mechanism for obtaining the target address records in such Also, an authoritative server that uses the client address to tailor
setups is unspecified; typically they will be resolved in the DNS in the response should obviously not use its own address when looking up
the usual way, but if an ANAME implementation has special knowledge ANAME targets, or it could direct clients to a suboptimal server
of the target it can short-cut the substitution process, or it can (e.g. a wrong language, or regional restricted content). Instead the
use clever tricks such as client-dependant answers. authoritative server should look up the ANAME targets on behalf of
the client address. It could use for example EDNS Client Subnet for
this.
In short, the exact mechanism for obtaining the target address
records in such setups is unspecified; typically they will be
resolved in the DNS in the usual way, but if an ANAME implementation
has special knowledge of the target it can short-cut the substitution
process, or it can use clever tricks such as client-dependant answers
to make the answer more optimal.
Appendix E. ANAME loops
The ANAME sibling address substitution algorithm in Section 3 poses a
challenge of detecting a loop between two or more ANAME records.
Imagine this setup: two authoritative servers X and Y performing
ANAME sibling address substition on the fly (i.e. they attempt to
resolve the ANAME target when the client query arrives). If server X
gets a query for FOO.TEST which is an ANAME to BAR.TEST, it will send
a query to server Y for BAR.TEST which is an ANAME to FOO.TEST.
Server Y will then start a new query to server X, which has no way to
know that it is regarding the original FOO.TEST lookup.
The only indicator of the presence of the loop in the described setup
is the network timeout. Ideally we would recognize the loop
explicitly based on the exchanged DNS messages.
On-the-fly ANAME substitution is allowed and it's just the most
obvious scenario where the problem can be demonstrated, but this loop
can also be encountered in other situations. The root cause is that
when the server gets a query it doesn't know why and that the server
always attempts to fully resolve the ANAME target before sending the
response.
TODO: Solve this issue [https://github.com/each/draft-aname/issues/45
[2]]
Authors' Addresses Authors' Addresses
Tony Finch Tony Finch
University of Cambridge University of Cambridge
University Information Services University Information Services
Roger Needham Building Roger Needham Building
7 JJ Thomson Avenue 7 JJ Thomson Avenue
Cambridge CB3 0RB Cambridge CB3 0RB
England England
 End of changes. 56 change blocks. 
173 lines changed or deleted 297 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/