Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

[Richard Gibson <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> 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=