Comments on the latest ANAME draft:
In Section 3.1, "records retrieved during ANAME <> resolution" looks
like a typo. Should "<>" be "<target>"?
Also in Section 3.1, the first five paragraphs could be more explicit
about resolving and adding address records instead of specifically A
and/or AAAA (other than as examples).
Also in Section 3.1, the final paragraph will result in universal
SERVFAIL responses if an ANAME target is in a misconfigured signed zone,
even if the zone containing the ANAME is _not_ signed (and a
corresponding traffic spike from ANAME-ignorant resolvers).
In Section 4, "resolution fails" should be better defined. Specifically,
may resolvers use server-provided records if their own query results in
NODATA or NXDOMAIN?
I think zone transfer considerations merit their own section, rather
than being buried in and mixed with DNSSEC in 3.3. And because of those
considerations, I consider it a mistake to prohibit secondary servers
from resolving ANAME targets when there are address records at the same
node as is required by Section 3.2. Behavior in error cases, including
those stemming from ANAME-ignorant participants, seems to be much more
preferable if such address records are treated as fallback data occluded
during healthy operation:
1. *ANAME-ignorant primary, ANAME-aware secondary*: The secondary will
have access to fallback data from the zone, but will only include it
in responses when its own ANAME target resolution fails. The
secondary can thus provide better answers to ANAME-ignorant clients
when responses for the ANAME target are tailored.
2. *ANAME-aware primary, ANAME-ignorant secondary*: Including expanded
records in the transferred zone data results in stretching ANAME
TTLs and failing to update anything until secondary refresh, but
/not/ including them would almost completely suppress ANAME
functionality. I think the tradeoffs here need further analysis;
more on that below.
3. *Address-including zone, address-lacking target*: An ALIAS-aware
server will be able to locally resolve answers from the target name
for address types that it has (e.g., A), while still providing
nonempty answers from the zone for those it lacks (e.g., AAAA). At
least Oracle [Dyn] customers actually prefer such behavior, as I
mentioned in
https://www.ietf.org/mail-archive/web/dnsop/current/msg20061.html .
But note that it requires authoritative servers to override NODATA
responses to ANAME target resolution, changing the last two
paragraphs of Section 3.1.
4. *Address-ignorant primary, address-aware secondary*: Assuming that a
new address record has been defined that the primary does not know
of, the secondary will be able to include locally-resolved data for
it, whether or not zone data includes the new type. In cases where
the zone data just hasn't been updated, this behavior is better than
assuming it has been pre-expanded to an empty set.
5. *Address-aware primary, address-ignorant secondary*: Assuming that a
new address record has been defined which the primary knows of but
the secondary does not, the transferred zone data should include
pre-expanded answers of the type so the secondary has them available
for its responses (since it doesn't know to look them up on its
own). This informs the question from case 2 above, but does not
completely resolve it (see below).
6. And layering DNSSEC on top of the above (i.e., assuming the
ANAME-containing zone is signed), *ANAME-aware secondary without a
zone-signing private key*: I agree that there is no reason for a
secondary to respond with data that it cannot sign, but it should
still include signed (fallback) data that ANAME-aware clients will
attempt to override with local resolution. But how is the XFR server
to know if the XFR client can add valid signatures?
Regarding zone transfers in which the secondary server is ignorant of
ANAME altogether, or the inclusion of a new address type, it seems clear
that primary servers capable of pre-expansion should do so. But in my
mental model, there's a distinction between static in-zone fallback data
and data that was resolved upstream (the latter subject to TTL
decrementing and local refreshes, the former not), and ANAME-aware zone
transfers should preserve the distinction even though resolution
responses won't. There's also the practical matter of zone serial, which
controls zone transfers but SHOULD NOT be updated by changes in non-zone
data like ALIAS target answers.
With all that in mind, I think ANAME will need to update the definition
of AXFR and IXFR, and IXFR in particular is likely to give ANAME a hard
time:
@ SOA serial=<N> ; PROBLEM 1!
; Use of an already-known serial (since static zone contents
have not changed).
; This may confuse ANAME-ignorant servers into ignoring the
XFR altogether.
@ SOA serial=<N> ; PROBLEM 2!
; This is a putative ANAME-enhanced IXFR of serial N to serial N.
; But at this point, it is indistinguishable from an AXFR of
a degenerate single-record zone.
aname A 192.0.2.1 ; removed ANAME expansion
aname A 192.0.2.2 ; PROBLEM 3!
; ANAME-ignorant servers must remove *all* previous ANAME
target expansions, but those are independent of serial.
; The servers may fail when asked to delete a nonexistent RR.
@ SOA serial=<N>
aname A 192.0.2.1 ; new ANAME expansion
@ SOA serial=<N>
I guess the above could be mitigated somewhat via a signal indicating
ANAME-awareness in the client, but that probably means AXFR of an
unchanged serial for ANAME-ignorant clients, which is a) incredibly
wasteful and inefficient, and b) /still/ not guaranteed to succeed as
far as I know.
There's also a similar problem for instructing secondary servers to
switch away from UDP—we essentially have to lie about having serial N+1
in the single-SOA UDP response, or else they will consider theirselves
already up-to-date and not even bother retrying.
On 01/12/2018 12:25 AM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Address-specific DNS Name Redirection (ANAME)
Authors : Evan Hunt
Peter van Dijk
Anthony Eden
Filename : draft-ietf-dnsop-aname-01.txt
Pages : 12
Date : 2018-01-11
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.
The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Daname_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=ulCMqQ4wONLJG9KK0IQABDgOA2c8Re-qj7QjvlccUmM&e=
There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Daname-2D01&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=lIM4rArEf1_3WZ-wc0OAMjrrQl7oPojbWnL5c-sWvyE&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddnsop-2Daname-2D01&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=zH9k0X0QisCnWUvpbFOYTUIPo-OXmY8eds60z-VhPyE&e=
A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddnsop-2Daname-2D01&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=dz9gowqhmuf5y-hhYE1mO53PxoJnMye_-MjScoWpsJQ&e=
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=KOnatQo8HbAQv2xzq5uohkI5K0barAUuYdIu9PMd_7Q&e=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=GiCIMlFzleSHBbNYaGcNmJZBGJ5cSZIsI9BMUp2y8qI&e=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
